D future ...

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 15 February 2017 at 10:38:04 UTC, Russel Winder 
wrote:
> It is also "re-tribalising" around the Rust, Go, Swift, C++17 
> for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on 
> the JVM; ECMAScript, TypeScript, Elm in the browser, and Python 
> in data science and such like. OK not orthogonal dimensions.

Yeah, it isn't orthogonal dimensions. Not quite sure what you 
mean by "re-tribalising". Do you mean that developers have broken 
up from older languages like C++98 and Objective-C and regrouped 
over Rust, Go, Swift and C++17? I guess that is a reasonable 
interpretation.

I am still not sure exactly what Rust's demographic is, but I 
guess it may be catering for those that want a high-level C with 
a preference for functional programming over templated 
programming?


> An interesting perspective is who is putting money into IDEs 
> and JetBrains are a good measuring device for this. C/C++ with 
> CMake got CLion which is now getting a lot of Swift and Rust 
> love. Go got a whole new IDE in Goglang. C#, Ruby, JavaScript 
> get a lot of push, as do the gamut of JVM languages in IDEA – 
> where the Rust plugin gets a lot of push. Python has PyCharm.

I haven't seen Gogland before, too bad I turned down the full 
suite IDE offering from JetBrains recently... VSCode with plugins 
is ok for Go and TypeScript though.

But it is a clear trend that newer languages are more tuned for 
IDE support, i.e. the language design is made with 
text-completion support in mind. This is one primary advantage 
with TypeScript over JavaScript for instance and alone worth the 
switch. Writing Python code with PyCharm is also quite different 
from using emacs, it is almost a "different language".

This trend will continue. Programming for iOS without XCode is 
unthinkable at this point, and similar situations exists for 
other platforms.

> Emacs, VIM, SublimeText, Atom, etc. get some love but few 
> people really care about them compared to the Eclipse and 
> JetBrains IDEs.

The cognitive load is just too high these days to use a regular 
editor if you want to be productive. The APIs are too big, there 
are too many of them, and they change too much and frequently to 
deal with "non-standard" editor issues. Just the automated 
hinting that something is deprecated and suggestions for 
replacements are invaluable time savers when upgrading codebases.

> So if we measure traction by IDE and editor effort D is losing, 
> along with Fantom, Crystal, Pony, Nim, and all the other 
> languages that focus on the language to the expense of the way 
> people use the language.

I think IDE support should be part of the core project these 
days. My impression is that Dart had a lot more enthusiastic 
following when they provided a Dart-editor (eclipse fork). 
JetBrains supports Dart, but it isn't really the same thing when 
it isn't free and directly supported by the language provider.

I noticed that the Whiley website says that they are maintaining 
an eclipse plugin as part of the project.

> Kingsley started work on the IDEA plugin and Bruno on the 
> Eclipse plugin. Some people are working on the IDEA plugin (I 
> am supposed to be as well, but I am failing). To get D out 
> there with traction, these, not the compiler, should be the 
> core focus of attention – the place where lots of resource is 
> going in.

One cannot expect volunteers to keep at it for years. And being 
left in the dark at some point in the future is not a very 
enticing prospect when adopting a language. There are currently 
more open source projects on github than (capable) developers... 
so one cannot expect others to take over either. It was different 
back in the day when emacs was the only real alternative.

Community driven development seems to no longer work reliably for 
projects that have high maintenance costs (with notable 
exceptions).

I guess this having something to do with the basic needs being 
met by the Linux ecosystem (the basic Unix toolset being 
available). Maslow's hierarchy of needs?

> Ceylon, Kotlin, Rust, Go have some core resource that attracts 
> more resource, and there is a snowball effect.

I think Go has benefitted some from having limited and stable 
language semantics and continuously improving on the 
implementation. IMO that should make it attractive in the server 
space, i.e. you get low tooling-related maintenance cost and 
still get real benefits from recompiling with new versions of the 
compiler.

I don't much about Rust and snowball effects? I thought Rust had 
stagnated, but maybe I am wrong?

> No matter how good D and the compilers are, without high 
> quality IDE support, it will be a peripheral language for the 
> core adherents.
>
> But we have been round this time and again, with 
> extraordinarily little progress.

The most important factor is the overall composition of the eco 
system and a good IDE makes it all come together. Kinda like a 
carpenter's workbench. You can make small scale stuff without, 
but you wouldn't do professional work on a tight schedule without 
a good stable workbench if can get one at another shop (language).

But a good IDE won't make significant change until the semantics 
for resource handling has been dealt with in a competitive 
manner... so there are several bits missing. Both Go, Swift and 
Rust provide "state of the art" memory management. D currently 
does not.