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!