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.
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".
2. It cannot compete with Go GC, not even in theory.
3. The current approach to C++ integration will become less and
less useful as C++ libraries are moving more and more heavily
towards templating.
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.
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).
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.
Apple might decide to delay the process to protect App Store..
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.
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.
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.
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.
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.
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.
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.
But it won't be unseated. Modern HTML5 has critical mass. WebGL
might be unseated.
Browser vendors will try to deprecate features instead. Google is
claiming that they will remove SMIL for instance.
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.
