TIOBE December 2015 - D rose 5 positions

Ola Fosheim Grøstad via Digitalmars-d digitalmars-d at puremagic.com
Tue Jan 5 08:54:32 PST 2016


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!





More information about the Digitalmars-d mailing list