zlacker

[return to "Zig Libc"]
1. OsamaJ+Ea1[view] [source] 2026-02-02 22:46:04
>>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
◧◩
2. LexiMa+Ra2[view] [source] 2026-02-03 05:44:31
>>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.

◧◩◪
3. Walter+0q2[view] [source] 2026-02-03 07:56:28
>>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
◧◩◪◨
4. WhereI+9N2[view] [source] 2026-02-03 10:58:27
>>Walter+0q2
This is the smart choice

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?

[go to top]