Zig ELF Linker Improvements Devlog

https://ziglang.org/devlog/2026/#2026-05-30

by kristoff_it • 2 months ago

227 102 2 months ago

ziglang.org

teabee89• 2 months ago

This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!

bcardarella2• 2 months ago

I wonder how much this work being pushed forward right now is a response to the Bun drama.

kristoff_it• 2 months ago

None of it, we've been working on this stuff for a long time already, scroll the devlog backwards, you will find plenty of entries on that topic.

It's the opposite: people have become more receptive to communication about this work now that there's "drama" attached to it.

This post I co-authored with Andrew is from 2020. In it we announce the idea of getting rid of LLVM from the debug build pipeline and since then work has been steadily going forward, it's just not trivial to bootstrap a full compiler pipeline for all major targets, but we're finally getting there.

https://kristoff.it/blog/zig-new-relationship-llvm/

bcardarella2• 2 months ago

I'm very glad to see the work, thank you for all of the efforts.

mi_lk• 2 months ago

Some people really can’t operate without stirring unnecessary drama.

What if that’s true and what if that’s not true?

dzbarsky• 2 months ago

None? All of these things were in flight for a while and given Zigs anti-AI stance i think they wrote off Bun ever since the acquisition

dnautics5• 2 months ago

what anti-ai stance? i have multiple projects in zig that are pretty much written by AI, no problem.

cafebabbe• 2 months ago

There is absolutely no "Bun drama", there are just two projects with different goals and methodologies, mutually incompatible. All this thing is just a small bunch of bored, terminally-twitting people ...

In any case, I'm super glad for this milestone (and impressed!).

bpavuk7• 2 months ago

I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust. even Andrew's initial dream - to create a DAW with uncompromising UX - will become much easier to create. once someone creates a Zig-native immediate-mode or reactive UI framework, that is.

I am still a little salty about `@cImport` removal, though! without it, I can't confidently call it "Kotlin of C" anymore.

gliptic• 2 months ago

Zig-native immediate-mode

dvui?

bpavuk7• 2 months ago

many thanks, will look into that...

alexboehm• 2 months ago

It's already sort of possible. https://codeberg.org/fellowtraveler/flux here is my Zig DAW. It has been amazing for the audio engine, but the ui is currently using imgui.

lukaslalinsky• 2 months ago

I've tried building your project, but hit problems due to dependency hash mismatches. Do you have a screenshot somewhere?

akazantsev• 2 months ago

Kotlin of C

That sounds good on paper. But as a guy who tried to learn Kotlin and only it. It comes with baggage to learn Java to use its libraries because... You know... they interact seamlessly and stuff. In the end, for a new learner, it might actually make things harder.

Nothing about Zig and C here, just a bit salty from my experience with Kotlin.

bpavuk7• 2 months ago

Kotlin <-> Java interop is a totally optional topic you could have skipped over, telling you as a Kotlin developer (who recently had to switch to .NET because Ukrainian job market is fucked up). besides, Java itself isn't that hard if it's Java 17 or newer, and it's rather good if it's Java 25 or newer

dapperdrake4• 2 months ago

Clojure also "comes with the baggage" of learning Java libraries.

And JavaScript comes with the baggage of learning about web browsers and NodeJS's "fs" module.

vips7L3• 2 months ago

Kotlin also has its own features that differ from the way the JVM or Java has decided to develop them. For example: coroutines vs virtual threads or Kotlin “value” classes and Java value classes. The semantics don’t match and Kotlin stops becoming simply a “better Java”.

vanviegen• 2 months ago

Kotlin is a terrible language for learning, as it has a lot syntactic shortcuts that are easy to mistake for magic. I think it's actually easier to learn some Java first, as it's simpler and teaches you the semantics both languages (mostly) share.

dnautics5• 2 months ago

idk, making @cImport just "@import" is an improvement imo.

bpavuk7• 2 months ago

`@import` that you have to configure in the build system first.

this makes porting projects gradually, file by file, rather cumbersome. now I have to rewrite quite a lot of Chocolate Doom because my port was halfway there and then @cImport got gutted... or keep going with Zig 0.16.2 until it's either 100% Zig or has little enough files that upgrading won't make my build.zig file implode in lines of code

kllrnohj2• 2 months ago

that will let me iterate at the speed of JS or Python with performance of C or Rust.

Didn't Go already do that?

I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement

Yes, and it will still only be useful in the same niche that C is because the entire philosophy of Zig is to essentially be like C. You're never going to interate at JS/Python speeds with Zig because you'll always be wrangling with memory lifecycles, object lifecycles, etc...

Rust is significantly different.

dapperdrake4• 2 months ago

Go is for the cases where GC works for you (many, many cases).

Zig is for when you need control over the allocator (also many such cases).

vips7L3• 2 months ago

Go is a terribly verbose language.

bpavuk7• 2 months ago

Didn't Go already do that?

no. GC pauses turn any serious systems work into hell.

Yes, and it will still only be useful [...]

this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui

Mawr• 2 months ago

Zig, Rust, and the likes are only viable in niches where C is viable

Pretty much correct, yes.

Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with performance of C or Rust.

Fundamentally impossible. C/Zig/Rust have 100% performance as a top goal, which has to be traded off with something else and that's always realistically going to be programmer work/effort/time.

You can't have a house built 100% fast but also 100% cheap and with 100% quality. At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.

once this linker and incremental compilation on other targets land,

In any case, why would a better linker and faster compile times of all things achieve this supposed goal?

Beyond being low level, Zig is still pretty memory unsafe and has you make choices about each allocation, making it unappealing as an applications language. Zig and Python are completely different worlds.

spease2• 2 months ago

You can't have a house built 100% fast but also 100% cheap and with 100% quality.

That’s essentially what technological development does, is make those tradeoffs more favorable.

bpavuk7• 2 months ago

At best you could cleverly abuse the law of diminishing returns and aim for ~80% in all three areas. That's basically what Go's trying to do.

then how does Zig achieve ~90%?

In any case, why would a better linker and faster compile times of all things achieve this supposed goal?

sub-100ms rebuild is actually more important as the project grows. when you iterate, you think differently. picking different colors or fonts or whatnot becomes much cheaper, so you are more willing to try

quikoa• 2 months ago

These improvements are quite promising and I'm looking forward to giving that a spin once it is released.

Will the Windows side for 0.17.x get some compiler improvements as well or is this Linux only?

squeek502• 2 months ago

Might not make it in time for 0.17 but there is a contributor making progress on the COFF linker: https://codeberg.org/kcbanner/zig/src/branch/coff_linker_wip

derefr• 2 months ago

So, this linker does fast incremental linking, which is great for development iteration speed.

But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?

dapperdrake4• 2 months ago

Research "cl:define-compiler-macro".

It has been done before.

And LTO is when the C people and the C++ people started to agree.

wsve• 2 months ago

For releases you're generally building it all at once in a merge request/deployment pipeline anyway

ksec• 2 months ago

Are there any other languages that offer similar compilation performance. The only one I know of or remember is Turbo Pascal.

mgrandl• 2 months ago

Isn’t go (with cgo disabled) still at least as fast to compile?

ozgrakkurt2• 2 months ago

Compilation speed isn’t that much of a factor of language as far as I can understand. It is more related to how optimization is done and how machine code is generated.

Also obviously it is about how fast the actual implementation of the compiler/build-system is.

mattgrice• 2 months ago

Definitely not true. Otherwise we would have really fast C++ compilers and no one would ever have implemented hacks like precompiled headers.

dapperdrake4• 2 months ago

This has drastically changed with "recent developments".

Iteration speed is everything now, if and only if you learn from the additional iterations.

pjmlp11• 2 months ago

Delphi, D, Nim, Go, C# / .NET Native / Native AOT, Oberon (any on the language family), Ada (depends on the compiler, 7 vendors),...

flohofwoe2• 2 months ago

FWIW, IME at least Nim isn't particularly fast when building, at least when compared to C projects. E.g. in the sokol-nim bindings I'm seeing build timings like:

    32743 lines; 0.953s

...building 32k lines of code in a second really isn't fast on an M1 Mac, and that's for a debug build without optimization.

brabel• 2 months ago

Everyone forgets D. It’s probably the fastest to compile, even faster than Go

librasteve4• 2 months ago

There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization.

Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increasingly in Raku Grammars. The new AST (6.e.PREVIEW) will bring much better introspection and high level optimization handles. So the potential to refactor/rewrite the VM for substantial speed gains is wide open.

Anyway those with skills and interest are welcome to join the -Ofun at https://raku.org/community

nagaiaida• 2 months ago

minor correction, moar stands for metamodel on a runtime, not meta-object aware runtime

librasteve4• 2 months ago

red face … thanks for the correction … I guess I should have looked at https://moarvm.org

GuB-42• 2 months ago

I am following Raku and Zig from afar, and they both share similarities in that both languages are "optimized for fun" in a way, so no surprize that they come together.

Zig focus on compilation speed and give developers control (even more so than C). Raku, as a Perl descendant is a giant toybox and there is no one telling you not to use them. Both have in common that they give a lot of freedom to developers, which is really enjoyable. They also have in common that they are not very mature and have a limited market share and fine with it, and a community that looks genuinely nice.

The opposite of Rust. The language has the "bondage and discipline" philosophy, kind of like ADA, the idea being that it does everything it can to stop you from making mistakes. There is a lot of value in that, but it is not particularly fun. Its community was similarly defined by rules, its code of conduct was infamous, again, it serves a purpose but to me, putting the rules forward doesn't make the community look like a fun place to be. And there is the evangelism, the Rust community is aggressive "rewrite it in Rust!", "no memory unsafe languages!", etc... I have never seen such attitude from the Zig community. Sure they love their language and will tell you it is the best in the world, but they will not say that you are wrong for not using it. As for Raku, they don't seem to care that no one else use their language, they just hope it will happen eventually if they continue going forward.

spease2• 2 months ago

the Rust community is aggressive "rewrite it in Rust!", "no memory unsafe languages!"

This is more of a meme than reality at this point.

librasteve4• 2 months ago

lol … fwiw we are as bemused by the situation as anyone (well, I am, I can’t really speak for anyone else). My take is that Raku (née perl6) got the worst of all worlds … divided the perl community, was 15 years in the making, got dragged into the reputational suction as the unreconstructed perl Titanic sank. All the same, it’s a wonderful reimagining of all the great things of perl from all the community RFPs and the genius of Larry and Damian and co and fixes most of the negatives and is now there and steadily improving and what’s not to like!

AndyKelley• 2 months ago

If you decide to try this, feel free to share your progress and struggles on IRC, ziggit, or ZSF zulip. Plenty of people would be interested in helping out.

Good luck and happy hacking!

librasteve4• 2 months ago

thanks! I have done a bit of work on Raku + Polars (ie the Pandas rewrite in Rust). This has been hampered by Rust lack of a binary FFI - so it has ended up running into unsafe keyhole surgery territory. My current feel is that we would need to move down to Apache Arrow and build a bunch of FFI / MOARMVM level scaffolding to keep it fast. Maybe take a look at COW at the same time.

Is any of that already lying around in Zig?

c0rruptbytes2• 2 months ago

i'm not cool and hip like hacker news devs, but I've been seeing Zig a lot, is this the new cool thing on the street? no more Rust?

agluszak• 2 months ago

Zig's been around for ~10 years. It's more low-level and lightweight than Rust. Different goals, different trade-offs. If Rust is the new C++, Zig is the new C.

c0rruptbytes2• 2 months ago

If Rust is the new C++, Zig is the new C.

thank you, this helps!

Ygg22• 2 months ago

Still no 1.0 version though. So technically it's year 0.

epolanski3• 2 months ago

It's a hard-to-dislike language in the niche of systems programming.

The author is strongly biased and opinionated on his architectural and design choices, and those choices resonate with many.

pjmlp11• 2 months ago

I don't like the @ all over the place and the approach to slurping source as structs for libraries.

I would faster get back to Modula-2 or Object Pascal.

onlyrealcuzzo7• 2 months ago

I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript.

The Zig team between 0.16 and this has really made me glad I chose Zig as the target instead of Rust - which probably would've been a lot easier to target (since it's already memory safe).

I believed it had the best build system design and was the best transpilation target, and I really believe that 6 months later.

The main reason I wanted no GC is because I think aliasing is the root of all evil, and I want a language with zero global complexity (but doesn't require a PhD to use).

keithasaurus7• 2 months ago

Working on something kinda similar. No GC, Python feel, managed memory, performance approaching C. It's here: https://blorp-lang.org if you want to compare approaches.

onlyrealcuzzo7• 2 months ago

It looks pretty cool!

It's not clear how much concurrency is part of what you're trying to solve.

All I could find is this: https://blorp-lang.org/docs/concurrency/ - which doesn't give me much as to how you handle shared memory, safety, deadlocks, etc.

Definitely down to chat more - looks like you've got some traction, which is impressive and awesome!

I'd love to pick your brain as it appears you're further along than I am.

androiddrew• 2 months ago

I really would like a 1.0, then I think it can actually be adopted by business.

up2isomorphism• 2 months ago

I don’t think either zig or rust can replace C, no matter how much this kind of work. They will of course improve its own language. The only language that can replace C is a language is as simple as C. None of them are simple language.

setheron• 2 months ago

Is there a design dock or explanation about how it can do incremental linking?

It's evaded other linkers in the past: gcc, llvm, mold etc....

Zig ELF Linker Improvements Devlog

Related Stories