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.
