If I'm writing C, it's usually a small module or algorithm that I link into another language. Since D is supposed to be in gcc now, I wonder if it's reasonable to start including D code in e.g. Perl or Ruby or Haskell libraries.
The great thing about C is once you write it, you never really have to worry about the language changing 15 years down-the-line and breaking your code. The GNU version might have a similar property, since GNU tools stay around for a long time.
D has been around for 21 years. It has had a compiler in the gcc project (gdc) for four years. It debugs easily enough under gdb. Several editors support D syntax (including geany and vscode). It has quite a few libraries (though its interoperability with C libraries has muted native D library development somewhat), centralized at https://code.dlang.org/
Are there specific parts of the ecosystem you worry about not being mature?
As for it being a bit esoteric, yes, it's not a very widely known language, though I'm not sure why. I fell in love with it in 2018, and it has thoroughly spoiled me for writing C.
I think D's approach is the right one. It's not a replacement for C, it's a supplement, with no barrier to entry. You can do all of the following: compile C code and call it directly from your D program (no bindings needed), compile D code and run it directly from your C program (no bindings needed), write C code using basically the same syntax but with some additional features (betterC), or write a D program and interoperate with C libraries without writing bindings.
I think a lot of C programmers dislike some parts of the language - something that's true of any language - but they like writing C code the way they have for the last X years. If they're willing to give up the preprocessor, they can keep using C. There's no need to replace C. D has support for all the platforms of GCC and LLVM. That's obviously not as many as C, but it's a lot.
I worked for a storage company whose product was written in D. They were later acquired by a larger international company, and I don't know what the fate of the original project was after the transition.
In this world, D was, while not a common choice, also not an unexpected one. The most common language for these sorts of products is C... but it's not the kind of C you'd find in books about the language. It's C that's heavily modded to remove or replace a bunch of stuff. D just happened to align well with what people running the project would've done to C anyways.
Also, in this context the existence of libraries doesn't matter, as almost everything is going to be written from scratch anyways. Nor does learning the language matter, since the internal infrastructure and learning how C was modified to fit the project goals would take the same time as learning another language.
To be honest, I really liked to work in that environment. Not because of any of D's features. I just hate being in the constant fear that I will not be allowed to do something that makes perfect sense, and instead coerced into idiotic workarounds that pretend to solve the problem. Which is what happens when you are required to use third-party libraries and they absolutely don't anticipate your use-case. It's the place where I was closest to being proud of what I was doing. Unlike most day jobs I had, where I felt like I need some extra time in the shower just to not feel dirty by writing code I knew full well should've never been written.
So what's the catch when it comes to D? If I can use all C libs easily, and get some more palpable syntax, what am I missing exactly and why haven't people transitioned to it?
D is a refreshing language in the sea of "alternative to C languages", they didn't reinvent the syntax, so if you come from C, using D will feel very natural and at home! (and you'll be protected from most unsafe/ub quirks of C)
When it comes to metaprogramming, it's excellent, but it is a double edged sword, it can be useful, but if abused it'll tank your build speed, so one must find a proper balance to avoid pain later
One of the few languages that offers its own backend! (LLVM/GCC backends are also available)
I love this level of independence, a real labor of love, one of the best better C, i'd even say this is the evolution C needed
D is one of those language that while it's technically very good, it's small eco system makes me look over it. I'm quite conservative about what libraries I rely on, and with these smaller languages 90% of the libraries you want are someones hobby.
The betterC scenario has intrigued me before though, it seemed like a win all around since you'd be using C libraries anyway. I'd love to hear others experiences and anecdotes with this.
There are a lot of places D does well, but if I had to pick one for which it is ideally suited, I'd say replacing C on a Linux/Mac/Windows desktop for app development or scientific computing. C is simply obsolete in those domains since D offers basically a superset of the functionality. In terms of interoperability, you can even #include C header files.
I think it's more useful than D though, because I can just add a header file to an old C project and make things better and still have things interoperate.
A decent subset of D programmers have used C and have been majorly bitten by it before, so it's definitely not a marriage of love put it that way. ImportC is, in my view, about optics and a little convenience - using C with D is already trivial if you understand how C works, ImportC just makes it offensively easy to do.
There are some less theoretical things too, i.e. no more keeping kernel headers up to date (apart from ones that use inline ASM that we have to be careful with).
With ImportC, D will be one of the better and non-hackier ways to interface C with other languages - i.e. introspection and metaprogramming but in a real language rather than some brain-dead DSL
I've not fallen down the D rabbit hole entirely, more focused on nim, but both of them can consume and spit out C APIs like nobody's business. See some great C lib you don't want to hack on, but do want to utilize? D should work well. Want to offer your library to the wider family of C-like languages? D can do it.
Walter bright and co. having designed the compiler so well sometimes makes you feel like your running a interpreter instead, so iterating on your code is comfortable as well.
I don't see much point in it. I've proposed this change to C in front of several audiences, and it never received any traction. If you want to experiment with it, you can use DasBetterC, i.e. running the D compiler with the `-betterC` switch, which enables programs to be built requiring only the C Standard Library.
Fair warning - once you get accustomed to DasBetterC, you're not likely to want to go back to C :-)
C will be here a long time, but it shouldn't be. There's still zero reason to write new code in C. None. If you need to integrate with a legacy codebase, fine. But for new code? C++ is better in every possible way.
Even when I only really need C, the contract programming that D provides is really helpful as it provides a macro free way of doing rigorous assertions etc. in a way that I can turn off without infecting the actual logic code.
If a struct's payload cannot be null, for example, getting the compiler to insert checks into all uses in debug builds can be done easily
That and metaprogramming in D is all compile time so you get RSI-free hands, for free.
Well, precisely : if people want modern/innovating/fast evolving languages, they can use Rust, Go, Elixir, etc.
I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). C is perfect for that, and I agree with the sentiment that backward compatibility is its most important feature.
Ultimately, though, this is the real tragedy of D. It started as a C clone, and continues to be named like it's a C clone, but it is no longer a C clone. It is a general-purpose memory-aware compiled programming language inspired by C++, but it is pretty different by now! People expecting a C clone miss what else it has to offer.
(Can it be a C replacement? Sure, but so can Rust/Swift/Go/etc)
The great thing about C is once you write it, you never really have to worry about the language changing 15 years down-the-line and breaking your code. The GNU version might have a similar property, since GNU tools stay around for a long time.
reply