On Tuesday, 5 January 2016 at 10:49:06 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 January 2016 at 04:19:33 UTC, Joakim wrote:
Because they're much higher up.
Yes, but the languages that are on the rise are cutting into
the existing languages. It is difficult to predict when they
hit a ceiling though.
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. Of course, some would say D already hit its
ceiling, ;) but a rebound is sometimes possible.
That's D's corner of the market, it was there long before Go
and Swift came after it. :) Of course, D doesn't get the hype
and automatic usage that those languages get because they're
from Google and Apple, but quality wins out in the medium-term.
I think D will loose the market for 80% efficiency and
automatic memory management without a redesign of
syntax/language semantics:
1. It cannot add ARC etc without becoming too like Swift,
because then Swift will win on tooling alone. Keep in mind that
Swift is getting "hygenic macros".
Walter seems against ARC anyway.
2. It cannot compete with Go GC, not even in theory.
Dunno about that, but Go cannot compete with D's @nogc.
3. The current approach to C++ integration will become less and
less useful as C++ libraries are moving more and more heavily
towards templating.
That's a separate issue from efficiency with automatic memory
management, but since I don't care about C++ integration at all,
not one I can say much about.
Seems to me that D's easy market is "embedded C++" and "better
C", with good platform support. Meaning: easy programming for
engines. That means the only real competitor is Rust.
But a focused choice has to be made, either D will go for the
"80% and ARC" or it will have to focus on beating "C/C++/Rust"
in the "engine"/embedded programming market.
Riding two horses won't make it. The design complexity for
enabling "easy programming" across the board grows non-linear
as the feature set expands. Apple is hellbent on making Swift
excellent for low level application programming ("80%
efficiency") and have C as a fallback for "100% efficiency" and
engines/libraries.
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.
But "easy programming" for embedded/engines/libraries is still
open as I think Swift won't make it, C/C++ is locked into a
corner and Rust have some barrier to entry issues (e.g. some
programmers won't get over the syntax and borrowing memory
management semantics).
I think Swift could go after that market, but they too will
probably have to add C++ integration to do it. C++ will never be
easy, but they seem to be trying to clean up to have a better
shot of grabbing some share there. I agree that Rust can't get
there, nor do they likely want to.
Maybe not 4-5, but yes, they're over-engineering a lot of this
stuff and adoption will take years.
I think it will take 2-4 years before we see compatible
"native" WebAsm in Safari, Firefox, Explorer and Chrome. Then
add 1-3 years for debugging and tooling... So actually, I think
2-5 years is a low estimate, maybe 3-7 years is more reasonable.
I was thinking more like 1-2 for the first iteration, and they're
considering debugging and tooling issues right now.
Apple might decide to delay the process to protect App Store..
It's not a significant enough source of revenue for them, I doubt
they care. Maybe only in the sense of having iOS exclusives,
which is really a benefit for the iDevices.
I have not looked at ECMAScript 7, but I have difficulty
believing any variant of javascript can ever beat out most of
those other scripting languages on the server.
It will have performant JIT and the ability to run same code on
server and client.
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.
I'm sure it will be pretty easy to recompile D2 to WebAsm
using ldc, as llvm will support it, so ldc can be easily
modified to support it.
Well, I think emscripten had to fork clang, so it takes more
than just llvm. Also, you need to do it well, so you have to
build a new runtime etc.
I wouldn't call it a clang fork, it doesn't look like they change
much:
https://github.com/kripken/emscripten-fastcomp-clang/commits/master
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.
And worse: solve debugging issues. JavaScript is debuggable.
Code translated into JavaScript is somewhat debuggable by using
source maps.
What will WebAssembly provide for debugging?
It is easy to forget that tooling is critical and can delay
adoption many years.
Maybe they'll build a gdb server into the browser, which you can
access remotely. :D
Unlikely, did you read that Tim Bray article I linked last
summer?
https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014
1. No, but I don't agree with him. Http is not so important.
Browsers support SPDY and HTTP/2. And websockets are coming.
2. Functional programming is not sufficient for solving
concurrency issues. Reactive programming does not scale. If you
want concurrency, you have to look to actor programming. It
scales in a robust way and allows you to mix different
technologies/languages.
3. No idea what he meant with storage. Scalable key-value
stores are commodity and a semi persistent version of it is
built into the browser.
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.
4. The only way that EcmaScript7 is not going to take over on
mobile for regular apps is to make langauges/tooling for
solutions like ios/Swift much better. If it isn't much better
then cross platform gravity will win. So it really depends on
what Apple/Google want.
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.
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. The
WebAsm push may even be based on another aspect of that, to
counter the notion that webapps cannot be efficient enough for
mobile.
Apple can sabotage EcmaScript7 on iOS in order to sabotage
cross platform apps on iOS.
I don't think Google will sabotage it on Android as they are
working on Dart-on-mobile-frameworks. And Android is the bigger
market over time.
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:
http://flutter.io
Any time a tech gets so bloated and complex, it's ripe to be
unseated by something simpler.
Well, JavaScript isn't bloated and complex. It is the
layout/render/animation engine for HTML5 that is complex.
Sure, javascript is only inefficient and messy. :)
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.
Browser vendors will try to deprecate features instead. Google
is claiming that they will remove SMIL for instance.
Never even heard of it, but I wish they'd just remove SVG
altogether. :)
budget down. The bloated web stack is long overdue for
similar disruption.
Nope. HTML5 is massive and fully cross platform. Other
platforms are highly unstable. Just look at iOS. It forces
developers to upgrade/rewrite for strategic reasons.
I don't want that. I don't want Apple to dictate when I have to
reimplement an app.
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.
On Tuesday, 5 January 2016 at 11:04:34 UTC, Ola Fosheim Grøstad
wrote:
Here is an overview of ES6, ES7:
http://kangax.github.io/compat-table/es6/
http://kangax.github.io/compat-table/es7/
As you can see, even ES6 has features that D lacks, like
destructuring, and it brings ES close to existing scripting
languages.
With ES7 you also get SIMD and language level async. At that
point only tooling will keep ES7 out of broad application
development.
I can totally see ES7 + C/C++ bottom layer take over cross
platform app development. Compile C/C++ to WebAssembly/native
and build the app in ES7 (or a language close to it).
Why would you bother with ES7 if you could just code it all in
most any language of your choice and compile to WebAsm?
Only sabotage can prevent it, IMO.
Or the web stack itself going away, which is very likely.
