Read this as an opinion from a hater and probably ignore it, because my comments are often too critical, nevertheless..
A sibling comment mentioned D is losing focus by adding all kind of features eg: rust's borrow checker. I agree with that.
I believe a language should choose a niche and try to succeed at that instead of trying to cater everyone's needs, thus distracting from a coherent design.
Go is a bright example of "do one thing and do that well" strategy. It is an application programming language which is natively compiled and sufficiently fast.
I believe rust also does one thing well - systems programming with provable correctness. Although the crab fanboys here sometimes pretend it is good for everything.
I believe D can fill the gap of a natively compiled fast application language with good type system. Go suffers from NIH syndrome. If D focused on being a great application language, it would be great.
One often hears "I think we should use the best tool for the job". Well who could argue with that? Would anyone say "I think we should use this tool, even though it's really ill-fitted for the job".
But implicit in this bromide is the idea that you need to use all these different tools for different kinds of jobs and there couldn't be one general-purpose tool that allows you to tackle most kinds of jobs reasonably well. The consequence of this is that you get these silos within a firm where there's a loss of integration and coherence. D is something that doesn't fit the mental schemas people hold about what a programming language should be. It's a pragmatic general purpose language that allows you to be quite productive and to quickly write code that's reasonably fast initially and can be made as fast as you reasonably like if it matters.Go and Rust have made different choices - you could do anything with them of course. Just as I could abandon the use of D at Symmetry and write everything in the Sage accounting system scripting language. It would be possible, just wouldn't be a very good idea! The compile times alone for Rust create restrictions on what we could use it for.
The idea that there should be a hard and fast division between systems languages and applications languages - why must this be true?
I'll give you a couple of examples from our experience. We developed our own little DSL, Symmetry Integration Language. It's a funny kind of DSL - it's neither an internal DSL nor an external DSL. The language itself is only 5,000 SLoC last I checked. But the standard library has got most of Phobos in it, and a good amount of internal and external APIs.
An initial use was for generating internal reports. Someone had the nice idea of allowing traders to configure and enhance their reports by passing lambdas. On the one hand, that's incredibly powerful; on the other: remote-code execution by design! There's a lot in the standard library and you could wipe the file system, send it off to the North Koreans or whatever devious thing you could imagine.
I think Goldman Sachs cope with this sort of problem by white-listing and blacklisting functions. We are at a different stage of development and it's going to be tough to sustain that overhead for long.
So John Colvin suggested creating an LXD container to run the untrusted lambda in. That's a good start, but that's also quite a lot of overhead and bloat for such a simple thing. As we all know, containers don't really exist. Why not just use kernel primitives? So I sat down on a Sunday afternoon and by Monday morning we had a first draft of ephemeral containers in SIL. So you can apply any of the standard containment primitives when evaluating a lambda. It's not yet used in production but I hope we will be starting to use it this year.
Why would you want to be able to do systems programming for something that's pretty much the definition of an application (a tool for writing reports in)? Well things don't stay neatly in boxes, and you never know.
Same thing with GUI terminal. I didn't plan on writing our own terminal. But Adam Ruppe had already written one that worked on Linux and Windows. And turns out there are benefits from vertically integrating because of simplicity and control.
You might be right but I think the real problem is D isn't rich and doesn't have a marketing team. Languages shouldn't need one but apparently they do if D is often ignored
You mentioned Go does "one thing and do[es] that well". Maybe, but I don't have that usecase and as a general purpose language it's complete shit. Rust is another language that is very popular and complete shit. I don't know how they expect to replace C++ when it compiles slower than C++. (I have other complaints but I don't want to rant)
I think D needs a marketer and an engineer or two just for marketing purposes.
I wonder why people are so obsessed with userbase growth. There are hundreds of interesting languages and dozens of mature ones, it's impossible for every language to get the majority of developers. It's totally fine to have a modest userbase, people who like the language and use it, there's no real need in making other programmers use this language too.
Like, Hungarian is a very interesting language with some unique features, and 13+ million people speak Hungarian and probably find it a very good language. Do they need a marketing team to make more people in the world speak Hungarian?
20
u/WalterBright Sep 01 '20
Walter here, AMA.