Ironically those optimizations came from .NET avoiding GC and introducing primitives to avoid it better.

And .NET is moving heavily into the AoT/pre-compilation direction for optimization reasons as well (source generators, AoT).

If you look at the change logs for the past few versions of the framework from perf perspective the most significant moves are : introduce new primitives to avoid allocating, move more logic to compile time, make AoT better and work with more frameworks.

So what, that is exactly the point.

A programming language having a GC doesn't mean every single allocation needs to be on the heap.

C# is finally at the sweet spot languages like Oberon, Modula-3 and Eiffel were on the late 90's, and unfortunely were overshadowed by Java's adoption.

Go and Swift (RC is a GC algorithm) are there as well.

D could be there as well on the mainstream, if there was a bit more steering into what they want to be, instead of having others catching up on its ideas.

That is what made me look into the language after getting Andrei Alexandrescu's book.

The point is that if you need performance you need to drop below tracing GC, and depending on your use-case, if that's the majority of your code it makes sense to use a language that's built for that kind of programming (zero cost abstractions). Writing C# that doesn't allocate is like wearing a straightjacket and the language doesn't help you much with manual memory management. Linters kind of make it more manageable but it's still a PITA. It's better than Java for sure in that regard, and it's excellent that you have the option for hot paths.

I rather have the productivity of a GC (regardless of which kind), manual allocations on system/unsafe code blocks, and value types, than going back to bare bones C style programming, unless there are constraints in place that leave no other option.

Note that even Rust's success, has triggered managed languages designers to research how far they can integrate linear, affine, effects, dependent types into their existing type systems, as how to combine the best of both worlds.

To the point that even Rust circles now there are those speaking about an higher level Rust that is supposed be more approachable.

This is essentially how I feel -- GC by default with user control over zero-copy/stackalloc behavior.

Modern .NET isn't even difficult to avoid allocations, with the Span<T> API and the work they've done to minimize unnecessary copies/allocs within the std lib.

(I say this as a Kotlin/JVM dev who watches from the sideline, so not even the biggest .NET guy around here)

> Writing C# that doesn't allocate is like wearing a straightjacket

Yes, and that's where D is majorly superior to C# -- it's flexible enough for you to go down to the metal for the critical parts.

That is the no longer the case in C# 14/.NET 10, D has lost 16 years counting from Andrei's book publishing date, letting other programing languages catch up to more relevant features.

You are forgetting that a language with a less mature ecosystem isn't much help.

> C# 14/.NET 10

Yes, they added AOT but it's still challenging to do anything that requires calling into the OS, because you're going to need the bindings. It will still add some overhead under the hood and more overhead will you need to add yourself to convert the data to blittable types and back.

Mixing C# with other languages in the same project is also difficult because it only supports MSBuild.

> You are forgetting that a language with a less mature ecosystem isn't much help.

Fair.

You also need bindings in D, nothing new there.

Rust also has issues using anything besides cargo.

> Rust also has issues using anything besides cargo.

D also has its own build system but it's not the only option. Meson officially supports building D sources. You could also easily integrate D with SCons, though there's no official support.

Well, you can do the same with Java and C#, assuming you actually know the ecosystem.

> You also need bindings in D, nothing new there.

You don't. Any D compiler is a C compiler too, so it can take C headers without bindings or any overhead added.

You have forgotten the footnote that not everything has a C API, not BetterC supports everything in ISO C, or common extensions.

Hint, before keeping to discuss what D can and cannot do, better go look how long I have been around on D forums, or existing projects on my Github.

> not everything has a C API

Anything that has stable ABI does.

> go look how long I have been around on D forums

You claimed higher up in this thread that D requires bindings to interoperate with C API. You don't seem that well informed really.

> Mixing C# with other languages in the same project is also difficult because it only supports MSBuild.

No, this is not true. You can invoke the compiler directly with no direct call to MSBuild what so ever.

Even using the dotnet command, which uses MSBuild under the hood, you are free to use your own build system. As an example - this code uses a Makefile to invoke the build: https://github.com/memsom/PSPDNA

If you want to call csc directly, it will compile with args just fine. And, if you have a working C# compiler on you platform, whether or not it uses MSBuild behind the scenes is kind of inconsequential.

You may also directly call the msbuild command, and it more or less does the same thing as the dotnet command, but hardly anyone eve calls msbuild directly these days.