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.

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

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

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.

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.

> who wants to write or generate C bindings?

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

Thank you for the kind words, Andy!

It's hardwired into the D compiler binary. It will even translate C macros into D code!

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.

Can't you just have one syscall(2) to rule them all? https://man7.org/linux/man-pages/man2/syscall.2.html

Good point. C's "freestanding" mode, analogous to Rust's nostd, does not provide any functions at all, just some type definitions and constants which obviously evaporate when compiled. Rust's nostd not only can compute how long a string is, it can unstably sort a slice, do atomic operations if they exist on your hardware, lots of fancy stuff but as a consequence even nostd has an actual library of code, a similar but maybe less organized situation occurs in C++. Most of the time this is simply better, why hand write your own crap sort when your compiler vendor can just provide an optimised sort for your platform? But on very, very tiny systems this might be unaffordable.

Anyway, C doesn't have Rust's core versus std distinction and so libc is a muddle of both the "Just useful library stuff" like strlen or qsort and features like open which are bound to the operating system specifics.

yeah I just thought there are "compiler shenanigans" involved with printf! zig's va arg being broken is sad, I am so zig-pilled, I wish we could just call extern "C" functions with a tuple in place of va arg =D

Calling this "properly" is a stretch at best.

I will say first that C libc does this - the functions are inline defined in header files, but this is mainly a pre-LTO artifact.

Otherwise it has no particular advantage other than disk space, it's the equivalent of just catting all your source files together and compiling that. If you thikn it's better to do in the frontend, cool, you could make it so all the code gets seen by the frontend by fake compiling all the stuff, writing the original source to an object file special section, and then make the linker really call the frontend with all those special sections.

You can even do it without the linker if you want.

Now you have all the code in the frontend if that's what you want (I have no idea why you'd want this).

It has the disadvantage that it's the equivalent of this, without choice.

If you look far enough back, lots of C/C++ projects used to do this kind of thing when they needed performance in the days before LTO, or they just shoved the function definitions in header files, but stopped because it has a huge forced memory and compilation speed footprint.

Then we moved to precompiled headers to fix the latter, then LTO to fix the former and the latter.

Everything old is new again.

In the end, you are also much better off improving the ability to take lots of random object files with IR and make it optimize well than trying to ensure that all possible source code will be present to the frontend for a single compile. Lots of languages and compilers went down this path and it just doesn't work in practice for real users.

So doing stuff in the linker (and it's not really the linker, the linker is just calling the compiler with the code, whether that compiler is a library or a separate executable) is not a hack, it's the best compilation strategy you can realistically use, because the latter is essentially a dream land where nobody has third party libraries they link or subprojects that are libraries or multiple compilation processes and ....

Zig always seems to do this thing in blog posts and elsewhere where they add these remarks that often imply there is only one true way of doing it right and they are doing it. It often comes off as immature and honestly a turnoff from wanting to use it for real.