41–50 of 62 posts
Earlier quoted context omitted.
The express purpose of the @nogc attribute is to enforce that code under it's influence doesn't use the GC. There is lots of @nogc code available to depend upon
In practice, "lots" isn't good enough. The whole ecosystem should work, not just lots.
Earlier quoted context omitted.
D never took off IMO because you can't abstract away a GC. The moment your callees rely on a GC, you have no choice but to have one in your program. The idea that you can avoid it in practice just because the language doesn't mandate it is therefore an illusion, and so it's not surprising at all that it isn't replacing C++.
This is the logic I personally used in deciding not to use D.
Good call - I was unfortunate enough that I had to use it professionally for a few years. As comic book guy in the Simpsons would say "Worst language ever!".
Earlier quoted context omitted.
In practice, "lots" isn't good enough. The whole ecosystem should work, not just lots.
In practice (I.e. actual practice that pays my rent) it's been good enough for me
If the answer is along the lines of "corporate backing", why did Rust get corporate backing and D didn't?
Earlier quoted context omitted.
Is your gcc plugin a personal project or something you built for a team ? I find the idea brilliant in itself but I wonder if other people felt the need, and uses / enjoy this kind of improvements. I want to add profile/coverage info in emacs now :) D is a strange point in PL landscape, it's been here for ages, never took off (for some value of taking off) even though it seems there's a lot to like.
D never took off IMO because you can't abstract away a GC. The moment your callees rely on a GC, you have no choice but to have one in your program. The idea that you can avoid it in practice just because the language doesn't mandate it is therefore an illusion, and so it's not surprising at all that it isn't replacing C++.
Earlier quoted context omitted.
This is the logic I personally used in deciding not to use D.
> This is the logic I personally used in deciding not to use D. Good call - I was unfortunate enough that I had to use it professionally for a few years. As comic book guy in the Simpsons would say "Worst language ever!".
Earlier quoted context omitted.
D never took off IMO because you can't abstract away a GC. The moment your callees rely on a GC, you have no choice but to have one in your program. The idea that you can avoid it in practice just because the language doesn't mandate it is therefore an illusion, and so it's not surprising at all that it isn't replacing C++.
I mean, the same is true for C++. If some C++ library you use employs GC, you can’t abstract that away either. The actual difference is how frequent such libraries are in the respective ecosystem.
Though, I'm not sure you could even have a precise GC for C++ even if you wanted to, given the way most C++ is written.
Earlier quoted context omitted.
In practice (I.e. actual practice that pays my rent) it's been good enough for me
Then why did D get lapped by Rust if @nogc is good enough and the ecosystem is good enough? If the answer is along the lines of "corporate backing", why did Rust get corporate backing and D didn't?
Also in a world where JavaScript (excel, even) is dominant let's not ascribe these things to purely rational factors.
Earlier quoted context omitted.
This is the logic I personally used in deciding not to use D.
Yeah, I'm pretty sure it's the reason many C++ folks reject it. It's kind of ironic that having the "wrong" useful feature can hurt you, but that seems to be what's happening here. I feel like they might actually have a shot at solving it by literally dropping GC support, but it's hard to say at this point. I don't know if the standard library still has anything that needs a GC, but making sure that's not the case mi…
Earlier quoted context omitted.
D never took off IMO because you can't abstract away a GC. The moment your callees rely on a GC, you have no choice but to have one in your program. The idea that you can avoid it in practice just because the language doesn't mandate it is therefore an illusion, and so it's not surprising at all that it isn't replacing C++.
I mean, the same is true for C++. If some C++ library you use employs GC, you can’t abstract that away either. The actual difference is how frequent such libraries are in the respective ecosystem.
That’s a difference without a distinction: people will use the defaults unless they can’t.
So in C++ libraries will avoid GCs unless their work basically requires it, whereas in D they’ll require it unless the author is constrained to a nogc requirement.
Earlier quoted context omitted.
Yeah, I'm pretty sure it's the reason many C++ folks reject it. It's kind of ironic that having the "wrong" useful feature can hurt you, but that seems to be what's happening here. I feel like they might actually have a shot at solving it by literally dropping GC support, but it's hard to say at this point. I don't know if the standard library still has anything that needs a GC, but making sure that's not the case mi…
Conveniences like closures depend on gc