Where will D sit in the web service space?

[Joakim via Digitalmars-d]

On Saturday, 25 July 2015 at 06:21:50 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 25 July 2015 at 03:44:23 UTC, Joakim wrote:
>> No, Swift is already general-purpose because it isn't highly 
>> optimized for a single purpose or feature and it's a fairly 
>> low-level native language which could be used to write 
>> everything from hardware drivers to webapps.
>
> Hardware drivers?

Why not?  If you can get FFT within 10% of C++, you could 
probably disable ARC, turn off dynamic dispatch, and write 
something reasonably fast.  It is a native language after all, 
just like D.

>>  In fact, I now see that Apple announced that they will be 
>> contributing a linux port when they open-source it later this 
>> year, so it won't even be tied to Apple's platform soon.
>
> GNUStep has existed for decades. And gone nowhere.

What does that have to do with Swift getting a linux port?  It's 
a lot easier to port and reuse a programming language than 
something like GNUStep.

>> As for Apple's "subconscious gratifications," considering I 
>> bought my first and last Apple product, a Powerbook G4, a 
>> decade ago and would never buy any of their products since, 
>> because of their crazy patent stance, that certainly doesn't 
>> describe me.  Ola brought up Swift as some sort of exception 
>> to the "general-purpose native languages on mobile" trend and 
>> I'm simply pointing out that's not true.
>
> http://www.primatelabs.com/blog/2014/12/swift-performance/
>
> Swift is 24x slower than C++ for FFT…

As your subsequent posts show, it can easily be made to be almost 
as fast as C++, since it's a native language.

> Standard apps on Android, iOS and in browsers rely heavily upon 
> the builtin rendering/animation engines of their platforms 
> (written in C/C++). The bottleneck for Javascript apps on 
> mobile is the animation engine and emulating the native GUI. 
> For the vast majority of apps Javascript itself performs well 
> enough.

For apps that are mostly GUI code, this may be true.  Still, 
google felt Java itself was enough of a bottleneck that they 
switched it from JIT compilation to AoT.

> For many mobile apps 80% of the code is GUI code. That means 
> you pay a high price for not using the default language and 
> TOOLING for the platform. As I've pointed out cross platform 
> GUI is no longer a realistic option since the Apple/Google have 
> differentiated their GUIs on purpose in order to make it harder.

Even if 80% is GUI code, the remaining 20% can slow you down.  
You don't have to use the default language and tooling in order 
to call the native GUI APIs, as you yourself pointed out with 
your MoSync example.  As for cross-platform GUIs, an app's GUI 
doesn't need to be the _same_ across platforms in order to be 
cross-platform.  Since the native GUIs can always be called from 
other languages, you could simply design a different GUI for each 
platform, by calling the native GUI APIs from one non-default 
language, say D, and use that same non-default language for all 
non-GUI code.  That way, you save some re-implementation time in 
each default platform language for the non-GUI code, at least.

Anyway, your point seems to be that native mobile is only taking 
off for superficial GUI reasons, but this ignores the fact that 
every mobile platform moved from higher-level and less efficient 
languages to lower-level native languages over time, from iOS's 
initial web sdk that was quickly ditched for Obj-C to the recent 
move by google to AoT-compile all the Java apps since Android 5.  
I guess they all did this for no reason at all.

> From a performance perspective you could probably do most 
> mobile apps in Javascript/V8 with no noticeable impact.

Performance?  Arguable, for apps that are mostly GUI code.  
Battery life?  No way.

> Btw, Dart has picked up the null-related-operators from Swift. 
> It also has async syntax sugar over Futures. It might 
> eventually be positioned as a mobile language for Android, 
> through Sky SDK and Material Design widgets.

Given the trend towards native/AoT compilation and that Dart 
doesn't fit in, I don't see it.