Do you have to bring up D in every Zig related post?
I 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.
He doesn't have to, he _gets_ to! Its knowledge exchange. Take it as a gift and not self-promotion. There's no money in this game so don't treat it like guerilla marketing. Treat it like excited people pushing the limits of technology.
>Do you have to bring up D in every Zig related post?
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.
I think the history of D having a garbage collector (and arguably exceptions / RTTI) from the beginning really cemented its fate. We all know that there's a "BetterC" mode that turns it off - but because the D ecosystem initially started with the GC-ed runtime, most of the D code written so far (including most of the standard library) isn't compatible with this at all.
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...)
My post was not about betterC, it was about the super easy interoperability of C and D. This capability has been in D for several years now, and has been very popular as there's no longer a need to write an adapter to use C source code. The ability to directly compile C code is part of the D compiler, and is known as ImportC.
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!)
This is, like, the most ironic comment ever posted on HN. An article about cat nutrition could hit the front page and the Rust fanbois would hijack the conversation.
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.
> claim that only Zig and C++ have ever had a strategy to replace C
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.
No, he never stated that "claim that only Zig and C++ have ever had a strategy to replace C", you made that up. And "Walter was not the one that brought up D" , he actually was.
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.
This is a bad comment in so many ways.
Walter's short limited comment was quite relevant.
C++ is more C-like than Zig and Rust, so it's more likely to become a C replacement.
I do feel like allowing for in-place source upgrading was critical to C++'s early successes. However, I feel like this ultimately worked against C++, since it also wed the language to many of C's warts and footguns.
C++ cannot seem to let go of the preprocessor, which is an anchor hurting the language at every turn.
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?
Except for all the baggage it carries along with it including hacks to address baggage resulting in a very bloated language.