TIOBE December 2015 - D rose 5 positions

[Joakim via Digitalmars-d]

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.