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.

> This talk explain why, it's not technical: https://www.youtube.com/watch?v=XZ3w_jec1v8

Really good talk, I remember watching it when it came out. Elm is what got me looking into FP several years ago, a nice language it was.

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.

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.

One good case for it that I see is a viable basis for cross-platform desktop apps. Today, cross-platform desktop GUI apps are either just a snapshot of the website contained inside Electron, or a C/C++ code base with manual memory management. D can serve as a nice middle ground in that space.

You'd be surprised to see how active the D community is, despite your fair point that it's noticeably smaller than in the "competing" (in quotes because it's not a competition, actually) languages.

The latest release [1] was on Jan 7th, and it contains more updates than, say, the latest release of Dart, which has one of the largest corporations behind it.

1. https://dlang.org/changelog/2.112.0.html

I'd rather say that the GC is the superpower of the language. It allows you to quickly prototype without focusing too much on performance, but it also allows you to come back to the exact same piece of code and rewrite it using malloc at any time. C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless.

Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point that you can eagerly free chunks of allocated memory, minimizing or eliminating garbage collector stops where it matters.

I'd say D's template error messages are much better than C++'s, because D prints the instantiation stack with exact locations in the code and the whole message is just more concise. In C++, it just prints a bunch of gibberish, and you're basically left guessing.

Yeah, I just saw his posts too and picked up the term :)

Well, I would say it's more like glasses - you can't convince those who don't wear them, and you don't need to convince those who need them either.

D and Rust are on the opposite sides at dealing with memory safety. Rust ensures safety by constantly making you think about memory with its highly sophisticated compile-time checks. D, on the other hand, offers you to either employ a GC and forget about (almost) all memory-safety concerns or a block scoped opt-out with cowboy-style manual memory management.

D retains object-oriented programming but also allows functional programming, while Rust seems to be specifically designed for functional programming and does not allow OOP in the conventional sense.

I've been working with D for a couple of months now and I noticed that it's almost a no-brainer to port C/C++ code to D because it mostly builds on the same semantics. With Rust, porting a piece of code may often require rethinking the whole thing from scratch.

On the flipside, with OOP is usually quite easy to put a debugger breakpoint on a particular line and see the full picture of what the program is doing.

In diehard FP (e.g. Haskell) it's hard to even place a breakpoint, let alone see the complete state. In many cases, where implementing a piece of logic without carrying a lot of state is impossible, functional programming can also become very confusing. This is especially true when introducing certain theoretical concepts that facilitate working with IO and state, such as Monad Transformers.

This is not true. It took about 20 years for Python to reach the levels of its today's popularity. JavaScript also wasn't so dominant and omnipresent until the Chrome era.

Also, many languages that see a lot of hype initially lose most of their admirers in the long run, e.g. Scala.