No question, just thanks for your hardwork and D contributor's. Diversity, competition and choice are important when it comes to programming languages.

Hello Walter, sorry for the (mostly) off-topic question, but is there still hope for having a variant of the standard lib that can be used w/o the garbage collector?

There is real momentum behind Phobos v2 now, can't give any promises about a timeline, but we're thinking about it, and Andrei is back in the fray now.

The standard library won't be a variant you can use without the GC but rather one that is allocator agnostic wherever reasonable

Do you think there's tension in Dlang trying be both a systems language like C++ AND a high level garbage collected language in C#?

Which is more important?

The only tension is for people that don't get how both are possible.

- https://en.wikipedia.org/wiki/Modula-3

- http://joeduffyblog.com/2015/11/03/blogging-about-midori/

- http://www.projectoberon.com/ (see https://www.astrobe.com)

- Eric Bier Demonstrates Cedar (https://www.youtube.com/watch?v=z_dt7NG38V4)

I'm somewhat in agreement.

There are a lot of people in 2021 who - for whatever reason - feel like they need to program personal computers without using GC. As you point history shows that's a lot less true than people think, but nevertheless - that is the sentiment.

Dlang tries spends a lot of effort trying to attract these people, by making more and more of the stdlib nogc, having @nogc annotations, experimenting with deterministic manual memory management etc etc. But I feel like they'll never convert most of them.

Meanwhile C# and Go keep being improved to play on the same place that D wants to be.

I also agree with the sentiment, the language issues with some not so well worked out features should be fixed, instead of trying to please everyone.

"... the language issues with some not so well worked out features should be fixed, instead of trying to please everyone."

This. For average programmers like myself, latest and fanciest language features are of little value. C++ and (unfortunately) D are in the same quest: to incorporate every programing language paradigm available, the extra complexity be damned. In the specific case of D, I'd rather have a good assortment of native D libraries than more bells and whistles added to the language.

Obviously I'm not Walter, but IMO, D's approach to GC does not create any tension. It's just a systems language with a GC that's there if you want to use it. You can disable it completely or only where you need to. Yes, you lose some features when you do so (like automanaged memory for dynamic array operations), but the tradeoffs are well-known and worth the loss when you need to make them. Consider WekaIO, which used D for their filesystem. No GC anywhere:

https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...

I think there's more to the tension than GC. GC is the red herring that everyone jumps to when it comes to such comparisons, but I think there are many more issues that could cause tensions. For example OOP features, inheritance, properties, that kind of things. For system programmer oriented folks these features are usually considered bloat, more high-level/application programmers consider them very valuable features.

For me currently D provides a good level of balance between those worlds, but the aforementioned GC isn't an issue for me at all so I have it easy.

Depends, the future could already have been here, instead of playing catchup with the past.

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

If you use D across your organization, you can use the GC for internal tools and scripts, while keeping high-performance product code GC-free. So it's not really a hindrance, as you don't have to use different languages.

This!

I think D should latch and promote more on the idea of having on-demand performance when it's necessary with GC convenience for the rest of the application. Soon having borrow checker capability ala rust and cyclone will only strengthen the narrative.

That's what we already do however the popularity of things we thought were obvious implies we need to market D better.

I usually write D code using both GC and manually managed memory. Tension between the two is like which is better, a socket wrench or an end wrench? Most of the time you can make either wrench work, but sometimes ya just need one flavor. Even a clawfoot wrench now and then!

Thanks for all your work, screenshot of my 2000's era DigitalMars CD :D -> https://imgur.com/a/SwlpZBR ( sorry for the gorilla hands )

I'll be starting my new DigitalMarsCoin soon, and rather than being a digital currency, it will rely on original Digital Mars CDs. Hold on to those CDs! The value will surge!

Is there a comparison with the other approaches, like htod? The PR describes them but does not say why this is better.

I've found over and over that building something seamlessly into the compiler is transformative, easily a factor of 10 in adoption of it.

The obvious examples are Ddoc, the builtin documentation generator, and unittest, the builtin unit tester.

You've been a compiler/language developer for many years now (many decades?). How did you get into this field of work? Do you have any regrets about this becoming your niche? :)

The answer to the first question is detailed in the HOPL IV paper, 'Origins of the D Programming Language', freely available here: https://dl.acm.org/doi/abs/10.1145/3386323

Regrets? I should have made it open source from the beginning! Stupid me.