| ▲ | WalterBright 2 days ago |
| 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. |
|
| ▲ | IshKebab 2 days ago | parent | next [-] |
| > 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.) |
| |
| ▲ | destroycom 2 days ago | parent | next [-] | | > "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. | |
| ▲ | WalterBright 2 days ago | parent | prev | next [-] | | > 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. | | |
| ▲ | motorest a day ago | parent [-] | | > 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. | | |
| ▲ | WalterBright a day ago | parent [-] | | 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". | | |
| ▲ | motorest a day ago | parent [-] | | > 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. |
|
|
| |
| ▲ | fl0ki 2 days ago | parent | prev [-] | | "The best thing about standard libraries is that there are so many to choose from" | | |
|
|
| ▲ | DannyBee 2 days ago | parent | prev | next [-] |
| 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 |
|
| ▲ | hyperman1 2 days ago | parent | prev [-] |
| 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. |
| |
| ▲ | WalterBright a day ago | parent [-] | | That's the result of having a lot of money behind it, and smart marketing. |
|
