On Tuesday, 5 January 2016 at 15:20:53 UTC, Joakim wrote:
I think Go's hitting its ceiling now. It will be interesting
to see what Swift's ceiling is: we'll find out if and when they
ever get it on Android.
The graphs for Go does not show a ceiling yet, but the
"theoretical" ceiling for Go is probably less than 25% of Java.
Go is not so attractive for spare time use (not so fun), so I
think Swift has a much higher ceiling if the OSS/Linux crowd
picks up support. Swift + C seems to speak quite well to their
needs actually.
Of course, some would say D already hit its ceiling, ;) but a
rebound is sometimes possible.
A rebound is very much possible with a new major release, like a
streamlined/polished D3 edition (just don't release it before it
is polished, lots of people come to try D if it comes to a 3.0 ,
so it better work perfectly at 3.0.0! :-). A good strategy is to
bring the semantics up on the 2.X line and then refurbish the
syntax for a 3.0 release. That way you have solid internals and a
fresh and shiny surface that will entice new and old users to try
it out.
D probably should aim for a lower ceiling and keep focus on
"advanced features". Go and Swift will try to stay "dumbed down",
like Java and C# to remain attractive to businesses that want low
in-house training.
Walter seems against ARC anyway.
In my experience on can get a long way with Unique (unique_ptr in
C++) and dynamic arrays. Then "manual ref counting" where it is
insufficient.
Dunno about that, but Go cannot compete with D's @nogc.
That's right, the scope of Go is quite limited.
Swift3 probably will try to get closer to C though. Apple seems
to be focused on making C less frequently needed.
Straddling both those horses appears to be the plan, taking D's
strength in 80%/GC and crossing over into low-level engine dev
with @nogc and C++ integration. Rather than splitting the
domains as you say Apple wants to, by complementing Swift with
C, I think the plan with D is to offer one language that does
both, ie a general-purpose low- to mid-level language.
Well... not sure how that works out. High risk! Hardware is
changing too. Runtimes/semantics can easily become obsolete
(inefficient) on new platforms. A reason to keep standard
libraries light.
Keeping things simple is good... Better to have 2 simple
languages than 1 big. Then you can replace 1 component when the
environment changes.
The situation for Apple is a bit different since they control
both hardware and software. Meaning, they can build in their own
Swift2Metal compiler if they want to...
I think Swift could go after that market, but they too will
probably have to add C++ integration to do it.
C++ is not big on the official iOS and OS-X frameworks. You
essentially have Objective-C and C as the legacy platform and
Swift and Metal with Objective-C compatible runtime as the modern
platform.
Objective-C++ is really only for binding to portable code from
other platforms.
I agree that Rust can't get there, nor do they likely want to.
Yep, Rust is kinda ML inspired. Seems to be more geared towards
"functional" high level and memory-safe-C + unique_ptr low level.
Which is a decent niche if they stay focused on it. They main
benefit of Rust seems to be that it is easy to enable
runtime-less programming. So it could take the embedded market
over time.
It's not a significant enough source of revenue for them, I
doubt they care.
$100 per developer per platform + 30% is a pretty hefty charge. I
don't trust the current Apple CEO... Steve Jobs was more "hacker"
oriented IMO.
Profit margins on hardware will drop as Android hardware become
commoditized. This is a typical trend. Margins go down over time
if you avoid monopolies and requirements stay the same. And
battery life and physical size limits requirements.
So, iPhone is a gold-mine today, but more like a copper-mine in
10 years? I guess flexible and unbreakable plastic phones could
be the next step, foldable LCDs are here already. Popularity of
fashion items are kinda bell-shaped (or something). 10 years ago
BIG SUVs were fashionable. Right now Teslas are fashionable here
in Norway... Just for show off, I think. :-/ Kinda like
JavaScript frameworks!
The v8 compiler has certainly helped javascript on the server,
but like I said, practically every language will be able to run
the same code with WebAsm, and they'll have a _lot_ more code
already running on the server.
Well. I think we will see legacy applications wrapped up in
suitable containers and stuck into the cloud in maintenance mode
while new projects go new routes. Fast interconnects (local
networking) and fast compute nodes makes it possible to continue
development in a new language and integrate software across
machines... I think.
As for the runtime, have you been following WebAsm closely
enough to know what it would require? I doubt it will take
much more than modifying druntime a bit and compiling to WebAsm.
No, my impression is that it currently is as limited as asm.js?
Unfortunately, I cannot find good documentation for the asm.js
environment. Seems like I would have to look at the emscripten
runtime! And that is just too tedious.
Please let me know if you find/know of a reference for the asm.js
environment, beyond the asm.js code gen.
Maybe they'll build a gdb server into the browser, which you
can access remotely. :D
I think that is the NACL way, actually. I've never gone beyond
"hello world" with NACL, so I don't know how well it worked.
But, having a built in debugger like we have for Javascript is
most likely much much better...
You can email him and take those issues up with him. I was
only linking it for the conclusion, that the current
client-side dev experience sucks and is likely to be disrupted.
My experience is that the client side dev experience is improving
greatly year by year! Both in general and as far as cross browser
compatibility is concerned. Safari is one step behind, but... IE
is moving. Microsoft is actually cooperating with Google. I think
they are better than Chrome in some aspects now.
Mozilla developer network and caniuse.com is your friend.
I think writing your business logic in a cross-platform
language like D, AoT-compiled Java/C#, or maybe eventually
Swift and your UI in the language native to the platform is the
more likely outcome, ie back to the pre-web standard for
cross-platform dev.
Mm... for games. Dart was a pretty solid language. ES7 is pretty
close to Dart. As long as Apple, Google and Microsoft backs it...
The web stack is so tough to deal with, especially because all
the different browser incompatibilities kill the cross-platform
story, that it's fading fast on mobile.
[...]
A big part of that is the popular and mostly dumb reasoning
that a web app's UI is not really "native" to mobile, but
whether dumb or not, that widespread perception hurts webapps
on mobile.
Right, it is problematic on mobile not because of cross browser
issues, but because the vendors have deliberately created
completely different look and feel on their platforms. And that
sucks for most apps, because they are dominated by UI code...
One solution might be to create a cool visual UI that is very
simple and intuitive and implement it in webGL. _when_ lower tier
mobile phones get decent GPUs. A few generations and it will be
reality YMMV.
Yep, mobile frameworks like google's new C++/Dart-based Flutter
shows they likely see webapps sputtering, which may also be why
they're giving up on ChromeOS as a standalone platform:
It is interesting that they are backing this. Hopefully they can
do it in a way that forces Apple to follow suit.
Sure, javascript is only inefficient and messy. :)
It is messy without a typed layer over it. But can be quite
efficient if you know what not to do. And it is top notch for
some things like dynamic regular expressions. Will destroy
anything written in C/C++, D or Rust.
The basic skill needed is to understand what is fast and why, and
use those fast mechanisms. Like building a regular expression
rather than manually search using a javascript look. Or using
typed arrays rather than javascript arrays.
But it won't be unseated. Modern HTML5 has critical mass.
WebGL might be unseated.
Heh, I don't think either has gotten very far yet.
WebGL support is close to usable. HTML5 is dominant.
Never even heard of it, but I wish they'd just remove SVG
altogether. :)
Will never happen. SVG support is strong across the board:
http://caniuse.com/#feat=svg
http://caniuse.com/#feat=svg-html5
http://caniuse.com/#feat=svg-html
http://caniuse.com/#feat=svg-css
http://caniuse.com/#feat=css-animation
You can use CSS on SVG elements and to some extent CSS animate
them. All vendors back this, even Microsoft. I recently replaced
SVG-SMIL with CSS animations.
Well, at least we agree that it's massive. :) iOS will always
have the Apple tax, but as long as it's the leading mobile app
platform by revenue, which I hear it still is by a significant
margin, that's a tax most devs are willing to pay.
The tax is not the problem. The problem is that they dictate
deprecation and removal. So when you update to the next version
of iOS you might have to rewrite more of your app than you care
for.
Like... next year maybe they will ban using assembly code in your
app.
That's not tax, it is a monopolistic dictator state.
Why would you bother with ES7 if you could just code it all in
most any language of your choice and compile to WebAsm?
Convenience. If I don't need speed it is much much more
convenient to be able to use the REPL and debugger on a live
application/web app.
Scenario: customer calls in and reports a problem with the app.
ES7 solution: I look at the app in the debugger and do some
"poking" on live data to figure out what the problem is. Then I
can quickly call back and say how fast I can fix the issue.
AoT solution: I have to fire up a local environment with a
debugger and then try to replicate the problem that might not
show up for some weird border line reason.
Or the web stack itself going away, which is very likely.
I'm not sure if you are serious or joking... I mean, the web
stack is not going away in my life time. I am barely been able to
get rid of IE9!
Critical mass, installed base and so on will keep the web stack
alive for decades!
