> You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations.
Yes but people wanted a language where you can't use GC.
> ???
"Which standard library should I use?" is not a question most languages have:
https://stackoverflow.com/q/693672/265521
Surely... you were aware of this problem? Maybe I misunderstood the "???".
> Don't underestimate the backing of a large and powerful organization.
Yeah it definitely matters a lot. I don't think Go would have been remotely as successful as it has been without Google.
But also we shouldn't overstate it. It definitely helped Rust to have Mozilla, but Mozilla isn't nearly as large and powerful as Google. The fact that it is an excellent language with generally fantastic ergonomics and first-of-its-kind practical memory safety without GC... probably more important. (Of course you could argue it wouldn't have got to that point without Mozilla.)
> "Which standard library should I use?" is not a question most languages have: > https://stackoverflow.com/q/693672/265521
There is no such question when using D2 either. It was only an issue with D1, which was discontinued almost 15 years ago and was irrelevant for longer.
> Yes but people wanted a language where you can't use GC.
What do you think of C and C++ coming with extensive guides for best practices and what features to not use? Even so, D comes with an @nogc attribute which won't let you use the GC. Ironically, people complain that @nogc actually does not allow use of the GC. You can also use the -betterC compiler switch to not use the GC.
Interestingly, Compile Time Function Execution works great with the GC, as one needn't have to do backflips to allocate some memory.
Mozilla is orders of magnitude larger and more powerful than the D Language Foundation.
> What do you think of C and C++ coming with extensive guides for best practices and what features to not use?
I feel that this is a disingenuous point and that you know better than this.
For example, the poster child of C++'s "don't use this feature" cliche are exceptions, and it's origins are primarily in Google's C++ stye guide.
https://google.github.io/styleguide/cppguide.html#Exceptions
If you cross-reference your claims with what Google's rationale was, you will be forced to admit your remark misrepresents the whole point.
You do not need to read too far to realize Google's point is that they have a huge stack of legacy code that is not exception-safe and not expected to be refactored, and introducing exceptions would lead their legacy code to break in ways that is not easy to remediate.
So Google had to make a call, and they decided to add the caveat that if your code is expected to be invoked by exception-free code, it should not throw exceptions.
Taken from the guide:
> Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
I wonder why you left this bit out.
If this is how you try to get D to shine, then you should know why it isn't.
C++ has a lot of features which are not best practices. For example, you're not supposed to use the builtin arrays anymore, in favor of vector<>.
Google's guide is not the only one. There are the Scott Meyers series "Effective C++" with things like "declare destructors virtual in polymorphic base classes". D's destructors in polymorphic are always virtual.
This brings up another issue with C++ - conflation of polymorphic structs with non-polymorphic structs. The former should always be passed by reference, the latter maybe or maybe not. What C++ should have done is what D does - structs are for aggregation, classes are for OOP. The fundamental differences are enforced.
How does one enforce not passing a polymorphic object by value in C++? Some googling of the topic results in variations on "don't do that".
> C++ has a lot of features which are not best practices. For example, you're not supposed to use the builtin arrays anymore, in favor of vector<>.
Again, you know better than this. I don't know why you are making these claims, and it's very disappointing to see you make whole sequences of them.
There are no "built-in" arrays in C++. There's C-style arrays, which are there for compatibility with C, and then there's C++'s STL. Since C++'s inception, the recommendation is to use C++'s containers. In STL, there is std::array and std::vector. Which one you pick, it's up to your use case.
This isn't a gotcha. This is C++ 101.
> There are no "built-in" arrays in C++. There's C-style arrays,
They're built-in arrays. The C++11 n3290 specification calls them arrays in section 8.1. The use of "array" is used regularly elsewhere in the specification. They are built in to the language. There is no warning from clang compiling C++ code that these should not be used.
The trouble with C++ builtin arrays is they have no bounds checking and promptly decay to pointers at every opportunity. Despite the obsolete nature of them, people still use them. There's no switch to turn them off.
Where's the C++ guarantee that code doesn't use those builtin arrays?
"The best thing about standard libraries is that there are so many to choose from"
D has only one.