zlacker

>>ingve+(OP)
250 C files were deleted. 2032 to go. Watching Zig slowly eat libc from the inside is one of the more satisfying long term projects to follow

>>OsamaJ+Ea1
That's something I've always admired about Zig.

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.

>>LexiMa+Ra2
D can import C files directly, and can do C-source to D-source translation.

D can compile a project with a C and a D source file with:

    dmd foo.d bar.c
    ./foo

>>Walter+0q2
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.

>>audunw+hJ2
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...)