Reasons to use D

[via Digitalmars-d]

On Friday, 11 September 2015 at 15:14:55 UTC, Chris wrote:
> the way it is. If not implementing breaking changes is an issue 
> in D, why do people put up with C++'s backward compatibility 
> then?

Because of the lack of alternatives... But it is possible to do 
both. It is possible to bring current D to a complete state and 
maintain it, and also create a subset of it.

In the JavaScript world you have various versions of JavaScript, 
TypeScript, TypeScript+React, TypeScript+Angular, they coexists. 
So, as long as you can easily interface between languages it is 
ok.

I think language designers should focus more on creating 
languages for writing libraries to use with other languages than 
creating host languages. I am very unlikely to use Rust and D as 
host languages (Swift, Objective-C, Python etc are more likely).

> If D implemented breaking changes on a regular basis, the 
> criticism would go along the lines of "One cannot use it, 
> because the code breaks all the time, stay away from it until 
> it's stable!". I've heard it all before.

Yes, sure. Getting what you have specced out and polished is 
important, because as we can see with Rust the number of 
contributors increase quite a lot when people sense that you are 
"close to being done, this is it". I guess because it is easier 
to defend investing "work time" then.

Then again it takes a looong time from you freeze to being 
totally production ready in most people's eyes. Go has been 
polished for 3 years and still need another year... But Go's 
commercial uptake is impressive for a relatively simple language. 
Rust needs a few more years, yep, I think so.

> At least this particular reviewer of D actually used it and he 
> or she does have points to take home and work on. However, I 
> can't help but think that it's only from D that people expect 
> miracles.

All languages suck at one level or another, which is why it is 
perhaps better to create smaller languages that interoperate with 
other languages really well, but I guess that vision is not so 
interesting, because adding a feature is easier and more fun than 
polishing what you have.

Often the runtime become more of an issue than the language. You 
don't want 4 big runtimes in the same executable.

There are good things about Perl 6 for instance, but it is just 
TOO big to keep in your head if you don't use it frequently. 
Which is a petty, because a focused string processing language 
would be a nice "sublanguage" to integrate with other languages.

Same thing with Haskell. I'd love to use Haskell for some very 
specific tasks, but not as main programming language for a 
project.

I think the JavaScript world is doing much better at the 
integration part than other platforms. There are now more and 
more browser-compilers where you can write code for various 
languages and have it compiled to JavaScript on the fly. Even 
OCaml:

http://zhanghongbo.me/js-demo/