TIOBE December 2015 - D rose 5 positions

[Ola Fosheim Grøstad via Digitalmars-d]

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.