Can you please elaborate what kind of decision to make on D? It's a general purpose programming language with excellent metaprogramming capability.
As a comparison, has Python decided what it wanted to be? A scripting language like Perl, data processing language like R, tool command language like TCL or web backend programming language like PHP or RoR? But nobody in their right mind will ever say Python need to decide on his direction when it grows old.
As you probably have known when Python is around 20 years old (like D today), it played second or third fiddle to PHP, TCL, Ruby (RoR), Perl and R in their respective domains, and at the time the growing pain into Python 3 is yet to happen. But looks where is it now?
Personally I think the D language foundation is already solid [1]. It just need a killer application for it to be more popular and well-known just like what RoR did to Ruby. And if you have a solid foundation, it will probably just a matter of time for it to properly take off.
An excellent language that keeps being rebooted with endless discussions on memory models, incomplete features, DIPs that were half implemented without documentation.
While they don't know where it should go, C#, C++, Swift keep adopting D like features, with their rich ecosystem.
D could have been C# on Unity, given Remedy experience with the language, instead not.
D's Metaprogramming was great 10 years ago, not when placed against C++20 metaprogramming, or the features arriving in C++23.
Don't you think it's a good thing to have choices of managed memory and not, or mix them together when necessary? I think it's a paradigm shift in programming for the better.
Programming languages used to stick to one programming concept for examples either imperative, functional or object oriented. But now most modern languages support at least more than two concepts to stay relevant.
Regarding other languages later adopting D like features, sure you can do that but the end results will probably be sub-optimal and clunky. For example, Python adopting array processing in Numpy library and becoming very useful and popular, but it will not be as seamless, intuitive and natural as R or Fortran array processing capabilities.
It is good to have choices, provided they are fully implemented and bug free, instead of jumping into the next possible solution.
Phobos still doesn't fully work with @nogc, DIP1000 is undocumented and now there is @life getting the spotlight, meanwhile the GC is stuck in early 2000 design, the std.allocators library is in experimental limbo for years.
Even if the results are cluky, they can double down on an eco-system in libraries, IDE tooling and OS support, that D lacks.
Currently the motto is Jack of all trades, master of none.
We are having a meeting to lay down a plan on memory safety in 2 hours time, so have faith.
Also DIP1000 isn't that badly documented these days, not brilliantly, but frankly I find that a lot of complaints come from people who weren't ready (this doesn't necessarily apply to you in particular, just that these attitudes spread) to understand it in the first place.
And what do you mean by OS support? I find that not many other languages take it as seriously as us?
Taking C# as example, I mean being able to do embedded stuff (Meadows, IoT Core), regular desktops, IBM mainframes, game consoles, and mobile OSes, without having to create my own compiler toolchain and self made druntime.
Like what? The company I work for has business logic, numerical code, a functional DSL, bindings to just about everything needed, fast and introspectable because they are under the same language.
