arcadia_leak

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

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

> 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 never get a second chance at making a good first impression.

There's a good number of younger programmers like myself who've never heard of D, say, before 2017 when those false claims were still true. Our first impression of D comes from its state today, which is not that far behind from other emerging languages.

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

Depends on what the multiplicand is.

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

Why yes, D is not the best choice if you're looking for instant profit.

You can use C but you are not forced to. In fact, you can write C and convert it automatically to D (though it will need some amount of manual editing afterwards). C is supported as a syntax option but it's still the same compiler for both under the hood. As rightly pointed out by the user above, you can write the same high performance code in the D syntax. The reverse is not true, though -- using high level concepts like classes and GC allocation is not supported in the C syntax.

D by definition meets the FFmpeg's criteria because it's also a C compiler. Because of that I never wondered how D performs in the benchmarks, as I know for sure that it can give me the performance of C where I need it.

It's true that there is no off the shelf tool that you can use right now to write your app, but it certainly doesn't prove that making such a tool is impossible or even complicated.

It makes sense for a complex productivity app (e.g. an office suite editor) to implement the UI from scratch anyway, and for that they may choose D. If Jane Street didn't pick OCaml, it would've died long ago -- in the same manner, some company might pick D to do UI or anything else really.

> D/C#/Java are valid options I'm never picking D

This is perfectly fair.

> D was in the perfect spot to fill if it did not make the GC decision

I just find it hard to believe that the GC is the one big wart that pushed everyone away from the language. To me, the GC combined with the full power of a systems language are the killer features that made me stick to D. The language is not perfect and has bad parts too, but I really don't see the GC as one of them.

> The fact that C# is becoming the GC language in game dev is proving my point.

Respectfully, it doesn't prove your point. Unity is a commercial product that employed C# because they could sell it easily, not because it's the best language for game dev.

Godot supports C# because Microsoft sponsored the maintainers precisely on that condition.

> C# C interop is pretty smooth

True, but you still need to either generate or manually write the bindings. In D, you just import the C headers directly without depending on the bindings' maintainers.

> If it was an actual C++ modernization attempt that stayed C compatible it would have seen much better

Any D compiler is literally also a C compiler. I sincerely don't know how can one be more C compatible than that.

> Yes, and the no-gc stuff was just attempts to backpedal on the wrong initial decision

I think that it was more of an attempt to appease folks who won't use GC even with a gun to their head.