Where will D sit in the web service space?

[via Digitalmars-d]

On Saturday, 25 July 2015 at 07:18:23 UTC, Joakim wrote:
>>>  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.

I somehow doubt that anyone outside those already using 
Objective-C/Foundation will pick up Swift. Time will show.

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

Well, those were not obvious tweaks in my book. Maybe Swift will 
improve in the future, I don't know.

> 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.

It did at least save them some memory and start up/warm-up time?

> 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.

Yes, people do that.

> 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.

All I really can say is that many scripting languages are fast 
enough for the typical logic you need in a regular mobile app... 
But both Google/Apple need a lock-in strategy to get unique apps 
on their platform. What killed Mosync as a project was IMHO the 
diverging GUIs and the competing cross platform solutions based 
on scripting-languages.

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

Few developers care about battery life when the app is actively 
used. It's not like end users will say "When I use the weather 
app my battery gets drained faster".  What matters are things 
like not doing frequent work when the app is idle.

Now, vendors might care and have many reasons for pushing their 
own platform.

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

I have no idea, it is all about tooling, ease of development and 
end user experience.

And iOS appears to be moving away from ASM and towards using an 
intermediate representation that is hardware independent. So not 
a strict trend towards native. The trend over the past 5 years 
appears to be going towards vendor specific solutions.