| ▲ | brabel a day ago |
| Completely agree after trying it. Anything that may throw an Exception requires GC. There goes 80% of D code you could use. The rest becomes inaccessible for other, similar reasons quite often. Try writing D with @nogc and it takes 10 minutes to understand that. They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib) |
|
| ▲ | dataflow a day ago | parent | next [-] |
| > Try writing D with @nogc and it takes 10 minutes to understand that. Thank you. Yes, exactly. The problems aren't even subtle; it's impossible to miss them if you actually try. I don't recall even finding a reasonable way to concatenate or split strings on the heap and return them without a GC, let alone anything more complicated. It boggles my mind that people repeat the talking point that it's somehow practical to program with @nogc when the most basic operations are so painful. Nobody is going to drool at the idea of spending days/weeks of their lives reinventing nonstandard second-class-citizen counterparts to basic types like strings just to use a new language. > They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib) I don't agree that it's lack of manpower that's the problem -- at least, not yet. I think it's primarily the unwillingness to even admit this is a problem (an existential problem for the language, I think) and confront it instead of denying the reality, and secondarily the inertia and ecosystem around the existing language outside the standard library. It's not like the problem is subtle (like you said, a few minutes of coding makes it painfully obvious) or novel. The language has been out there for over a decade and a half, and people have been asking for no-GC version nearly that long. Yet, at least to the extent I've had the energy to follow it, the response has always been the canned you-can-totally-program-D-without-a-GC denials you see repeated for the millionth time here, or (at best) silence. If this sentiment has changed and I'm unaware of it, that's already significant progress. Maybe the unwillingness to confront reality is due to the lack of manpower and how daunting the problem looks; I'm not sure. But it seems as bright as daylight that D is not going to be successful without solving this problem. |
| |
| ▲ | WalterBright a day ago | parent | next [-] | | I use: https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba... It's pretty minimalist on purpose. I don't much care for kitchen sink types. The BetterC is the no-gc version. Use the -betterC switch on the compiler. Or, if you want a string result, import core.stdc.stdlib;
string concat(string s1, string s2)
{
const length = s1.length + s2.length;
char* p = cast(char*)malloc(length);
assert(p);
p[0 .. s1.length] = s1;
p[s1.length .. s1.length + s2.length] = s2;
return cast(string)p[0 .. length];
}
I tend to not use this sort of function because it doesn't manage its own memory. I use barray instead because it manages its memory using RAII. D provides enormous flexibility in managing memory. Or, you can just leave it to the gc to do it for you. | | |
| ▲ | dataflow a day ago | parent [-] | | > I use: https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba... It's pretty minimalist on purpose. I don't much care for kitchen sink types. I feel you're demonstrating exactly the problems I highlighted through your example here -- including the very lack of acknowledgment of the overall problem. | | |
| ▲ | WalterBright 21 hours ago | parent [-] | | The problem is there is no such thing as a string type that doesn't have problems one way or another. The very simplest and straightforward way is to use the gc to manage the memory. It works very very well. All the other schemes have serious compromises. That's why you can use the method most appropriate in D for the particular usage. I routinely use several different methods. |
|
| |
| ▲ | Zardoz84 a day ago | parent | prev [-] | | Part of the problem it's trying to do too many things in too many fronts.
They try to implement a borrow-checker a la Rust. But feels very poorly compared against the Rust version.
It haves a "optional" GC, but it's a subpar GC. And lacks a way to use alternative GCs. And funny, C++ has been copying many features that DLang have for many time ago. Beginning with the type inference (ie using "auto" to declare vars). And now, contractual programing and static reflection. I really loved the language, but it's very sad that never manages to take off and become more popular and well maintained. | | |
| ▲ | WalterBright 3 hours ago | parent | next [-] | | > But feels very poorly compared against the Rust version. It's a prototype to gauge the interest in having a borrow checker in the language. I did not continue with it because the interest is not there. | |
| ▲ | pjmlp a day ago | parent | prev | next [-] | | That has been the main problem from my point of view, too much pivoting looking for the right crowd, without finalizing what was done before. And while some features in other languages might have seen an implementation first in D, claiming first to the finish line as it usually comes up, even on this thread, hardly does anything for language adoption. On the contrary, it is one reason less leave those languages, as eventually they get the features, and already have the ecosystem. | | | |
| ▲ | gpderetta a day ago | parent | prev [-] | | > Beginning with the type inference (ie using "auto" to declare vars). GCC (and possibly other compilers) had typeof in the '90s well before D was first released. Macros in the form: #define TYPEOF(name, expr) typeof(expr) name = expr
Were widely in use since then.I'm sure that C++ borrowed concepts from D, but type deduction (not inference BTW) is not one of them. | | |
| ▲ | WalterBright 3 hours ago | parent [-] | | Extensions are not part of the language, which means that programmers tend to avoid using them. |
|
|
|
|
| ▲ | bachmeier a day ago | parent | prev [-] |
| This completely misses the point of my original comment. A C programmer that wants to continue to use their knowledge and existing code will be very happy using D. You're describing someone that wants to use D without the garbage collector. Those are two completely different cases. I've been happily using D for a better experience with C code for more than a decade. First, because it's extremely rare to need to completely avoid the GC for everything in your program. Second, because everything you want and need from C is available, but you can use it from a more convenient language. Sure, exceptions won't work if you're avoiding the GC (which doesn't have anything to do with C), but so what. It's not like C programmers are currently using exceptions. You can continue to use whatever mechanism you're using now. |
| |
| ▲ | zem a day ago | parent [-] | | > Sure, exceptions won't work if you're avoiding the GC (which doesn't have anything to do with C), but so what. It's not like C programmers are currently using exceptions. that works if your main use case for d is as a top-level wrapper program that is basically calling a bunch of c libraries. if you want to use d libraries you will run into ones that need the gc pretty quickly. | | |
| ▲ | WalterBright 3 hours ago | parent [-] | | I don't see how GC allocate exceptions would be a problem unless you're generating thousands of exceptions. Throwing an exception should, by definition, be an exceptional case. |
|
|