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

	▲	WalterBright 2 hours ago \| parent [-]
		If you don't mind waiting 10 years, sure!

▲ 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 2 hours ago \| parent [-]
		Extensions are not part of the language, which means that programmers tend to avoid using them.