Hacker News Reader

Comment by dataflow | Hacker News Reader

> If you're a C programmer and want to avoid the GC, there's nothing to be viral.

What you're suggesting is the moral equivalent of "it's easy to avoid diseases, just avoid contact with those infected", or "it's easy to avoid allergens, just avoid foods you're allergic to", or "it's easy to avoid contamination, just set up a cleanroom", or "it's easy to write deterministic code, just avoid randomness", etc.

Yes, there are things that are easy to achieve in the vacuum of outer space, but that's not where most people are interested in living.

View on HN

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)

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

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.

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

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.

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.

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.

If you don't mind waiting 10 years, sure!

I have been waiting for a good story how to sell D for adoption, since Andrei published his book.

Most of the stuff that interested me back in 2007, is now available across in C#, F#, JVM languages, Swift, OCaml, Haskell, with a better ecosystem and IDE tooling.

And then there is C++26 and Rust 2024.

You achieved a lot as language designer, but it is still not clear how the community would keep the language going forward in lets say 10 years from now.

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

Extensions are not part of the language, which means that programmers tend to avoid using them.

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

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.

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

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.

well, they're a problem for people who want to strictly avoid gc on principle, but I agree exceptions are a pretty mild case

Errors aren’t exceptional. They happen all the time.

According to them[0], D as better C is indeed just C with less footguns and some additional optional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use or ignore).

I don't think what hinders their adoption is their direction, everything they say they accomplished/plan to accomplish is ideal IMO.

[0] : https://dlang.org/spec/betterc.html#retained

> D as better C is indeed just C with less footguns and some additional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use, or ignore)

Having strictly more features (if we even assume that, which I don't think is accurate) does not imply better.

Javascript is just JSON with more features too. Is it a mystery that people don't ship Javascript code everywhere instead of JSON?

What the "more features" do is replace the clumsy/inadequate/risky methods used in a less powerful language like C. For example, you don't need to use the C preprocessor to do metaprogramming. D offers a world class metaprogramming capability.

Another example is D enables nested functions. Yes, there are ways in C to do the equivalent, but they are clumsy and indirect.

Reply on news.ycombinator.com