A lot of languages claim to be a C replacement, but Zig is the second language I've seen that seemed like it had a reasonable plan to do so at any appreciable scale. The language makes working with the C ABI pretty easy, but it also has a build system that can seamlessly integrate Zig and C together, as well as having a translate-c that actually works shockingly well in the code I've put through it.
The only thing it didn't do was be 99% compatible with existing C codebases...which was the C++ strategy, the first language I can think of with such a plan. And frankly, I think Zig keeping C's relative simplicity while avoiding some of the pitfalls of the language proper was the better play.
D can compile a project with a C and a D source file with:
dmd foo.d bar.c
./fooI do like D. I've written a game in it and enjoyed it a lot. I would encourage others to check it out.
But it's not a C replacement. BetterC feels like an afterthought. A nice bonus. Not a primary focus. E.g. the language is designed to use exceptions for error handling, so of course there's no feature for BetterC dedicated to error handling.
Being a better C is the one and only focus of Zig. So it has features for doing error handling without exceptions.
D is not going to replace C, perhaps for the same reasons subsets of C++ didn't.
I don't know if Zig and Rust will. But there's a better chance since they actually bring a lot of stuff to the table that arguably make them better at being a C-like language than C. I am really hyped to see how embedded development will be in Zig after the new IO interface lands.
You keep compatibility with C, can tap into its ecosystem, but you are no longer stuck with outdated tooling
D gives you faster iteration, clearer diagnostics, and a generally smoother experience, even if it doesn't go as far as Rust in terms of safety
I wish more languages would follow this strategy, ImportC is great, let's you port things one step at a time, if required/needed
Let's be honest: who wants to write or generate C bindings? And who wants to risk porting robust/tested/maintained C code incorrectly?
In this case, however, Walter was not the one that brought up D. He was replying to a comment by someone promoting Zig with the claim that only Zig and C++ have ever had a strategy to replace C. That is objectively false. There's no way to look at what D does in that area and make that sort of claim. Walter and anyone else is right to challenge false statements.
Walter's short limited comment was quite relevant.
Did the text get changed? because it seems you claim exactly the opposite of what is in about ~5 sentences, so it also can't be credited to "misunderstanding".
But didn't find any "D evangelism" comments in his history (first page), but then again, he has 78801 karma points, so I am also not going to put energy in going through his online persona history.
I'm not so familiar with D, what is the state of this sort of feature? Is it a built-in tool, or are you talking about the ctod project I found?
In most languages, I've found that source translation features to be woefully lacking and almost always require human intervention. By contrast, it feels like Zig's `translate-c` goes the extra mile in trying to convert the source to something that Zig can work with as-is. It does this by making use of language features and compiler built-ins that are rather rare to see outside of `translate-c`.
Obviously the stacks of @as, @fooCast, and @truncate you are left with isn't idiomatic Zig, but I find it easier to start with working, yet non-idiomatic code than 90% working code that merely underwent a syntactic change.
If D really wants to compete with others for a "better C replacement", I think the language might need some kind of big overhaul (a re-launch?). It's evident that there's a smaller, more beautiful language that can potentially be born from D, but in order for this language to succeed it needs to trim down all the baggage that comes from its GC-managed past. I think the best place to start is to properly remove GC / exception handling / RTTI from the languge cleanly, rewrite the standard library to work with BetterC mode, and probably also change the name to something else (needs a re-brand...)
What I actually said was that it was the second language I have seen to do so at any appreciable scale. I never claimed to know all languages. There was also an implication that I think that even if a language claims to be a C replacement, its ability to do so might exceed its ambition.
That said I also hold no ill will towards Walter Bright, and in fact was hoping that someone like him would hop into the conversation to try and sell people on why their language was also worthy of consideration. I don't even mind the response to Walter's post, because they bring real-world Dlang experience to the table as a rebuttal.
On the other hand, I find it difficult to find value in your post except as a misguided and arguably bad-faith attempt to stir the pot.
One interesting result of ImportC is that it is an enhanced implementation of C in that it can do forward references, Compile Time Function Execution, and even imports! (It can also translate C source code to D source code!)
BTW, in my C days, I did a lot of clever stuff with the preprocessor. I was very proud of it. One day I decided to replace the clever macros with core C code, and was quite pleased with the clean result.
With D modules, imports, static if, manifest constants, and templates the macro processor can be put on the ash heap of history. Why doesn't C++ deprecate cpp?
Well, most macros. The macros that do metaprogramming are not translatable. I read that Zig's translator has the same issue, which is hardly surprising since it is not possible.
So, yes, the translation is not perfect. But the result works out of the box most of the time, and what doesn't translate is easily fixed by a human. Another issue is every C compiler has their own wacky extensions, so it is impractical to deal with all those variants. We try to hit the common extensions, though.
If you just want to call C code, you don't have to translate it. The D compiler recognizes C files and will run its very own internal C compiler (ImportC) to compile it. As a bonus, the C code can use data structures and call functions written in D! The compatibility goes both ways.
Not me, and not anyone else. Many D users have commented on how ImportC eliminates the tedium of interfacing to me.
And with D, you don't have to write .h interface files, either (although you can, but it turns out pretty much nobody bothers to).
I dont think that is the case here, and in all previous encounter. I see this every time Ada was mentioned in Rust as well.
He is not brining up about D in every Zig post, he is simply replying whenever people said something about only in Zig, he is replying that D could do it as well. Which is fair.
Same with Ada, when Rust people claim to be the only language doing something, or the safest programming languages, there is nothing wrong in providing a valid, often missed out counter argument.
A subset of D could have been better C, or "Das C". Unfortunately I dont see anyone craving that out as a somewhat separate project.