Comment by IshKebab | Hacker News Reader

Comment by IshKebab | Hacker News Reader

Parent Full thread

I think D failed to gain widespread traction for other reasons though:

1. The use of garbage collection. If you accept GC there are many other languages you can use. If you don't want GC the only realistic option was C++. Rust doesn't rely on GC.

IIRC GC in D is optional in some way, but the story always felt murky to me and that always felt like a way of weaseling out of that problem - like if I actually started writing D I'd find all the libraries needed GC anyway.

2. The awkward standard library schism.

3. Small community compared to C++. I think it probably just didn't offer enough to overcome this, whereas Rust did. Rust also had the help of backing from a large organisation.

I don't recall anyone ever mentioning its improved safety. I had a look on Algolia back through HN and most praise is about metaprogramming or it being generally more modern and sane than C++. I couldn't find a single mention of anything to do with safety or anything on your list.

Whereas Rust shouts safety from the rooftops. Arguably too much!

> I think D failed to gain widespread traction for other reasons though:

D's selling only proposition was providing C++11 features in a point in time between C++98 and C++11 when the C++ committee struggled to get a new standard out of the door.

Once C++11 was out, D's sales pitch was moot, and whatever wind it had in it's sail was lost and never recovered again.

It's interesting to note that Rust, in spite of all odds and also it's community, managed to put together a far more compelling sales pitch than D.

Using D does not require a garbage collector. You can use it, or not, and you can use the GC for some allocations, and use other methods for other allocations.

D has a lot of very useful features. Memory safety features are just one aspect of it.

> The awkward standard library schism.

???

Don't underestimate the backing of a large and powerful organization.

> 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.

To your last point, the social/etc component of success always seems to be overlooked on HN. The world is littered with good solutions to problems that simply failed to get traction for various complex social reasons. There doesn’t have to be a technical reason something was not adopted widely. It could be fine, great even, and still just not get traction. I would bet everyone can name a piece of software they use that is not really popular at all, and everyone else uses something else that is popular, but this unpopular software really solves a problem that they have and they just like it.

Software never was a technical meritocracy.

There does not have to have been anything technically wrong with D for it to not have been widely adopted. I think HN doesn’t like that because it often means that there’s nothing obvious they can necessarily do to fix it

I've been on the edge to try out D a few times now, and always decided for No in the end.

For me, it was missing presence in the IT news that did it. D might be great, but it makes no noise.

Rust or go had a lot of articles and blog posts going deep into specific posts, appearing at a regular rate. They tended to appear on e.g this hacker news, or reddit, etc... This caused a drip feed of tutoring, giving me a slow but steady feel for these languagee. There were people tirelessly correcting misinformation. There were non stop code examples of people doing stuff with the language, proving the language usable in all kind of situations.

That's the result of having a lot of money behind it, and smart marketing.

I'd say No on the lot of money, as small scale marketing by a smart person can be enough.

Nginx had the guy translating the manual from russian. Ruby had the person with the weird poetic manuals. Rust had Steve Klabnic and others.

You need someone who is both a technical person and a communicator, being active on fora, doing advent calendars, blog posts, etc... Rust jumped in a hole where D could also fit, and D might be easyer than rust. I think the background interest in D exists, but has nothing to crystallize around.

Reply on news.ycombinator.com