alt.hn

5/30/2026 at 5:29:22 PM

Zig ELF Linker Improvements Devlog

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

by kristoff_it

5/30/2026 at 6:19:41 PM

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.

by bpavuk

5/31/2026 at 12:21:54 AM

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

by kllrnohj

5/31/2026 at 12:53:28 AM

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

by dapperdrake

5/31/2026 at 8:03:17 AM

> 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

by bpavuk

5/31/2026 at 11:45:25 AM

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

did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter

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

Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?

by kllrnohj

5/31/2026 at 2:39:54 PM

> They were comparing

that was me comparing, please kindly read usernames next time :)

> why not just choose a language that doesn't compromise itself for those ideals in the first place?

I might want to wrap a timing-sensitive machinery into some nice UI. Rust has Tauri for that, sure, but now we are bringing npm and have zero chances of having GPU-accelerated UI without a crap-ton of fuckery which would be easier in Zig. another path for resolving that same issue is Compose Desktop + Project Panama, but then you are dealing with data marshalling, FFI boundary, and manual resource management in an environment that does not expect this.

so, here is a genius idea: why not have everything in one language? C++ already does that, much like C, but Zig does that so much better, and incremental compilation time is one of the more practical and immediate developer UX benefits it provides. Rust? good luck having shared mutable state there.

by bpavuk

5/31/2026 at 12:53:51 PM

Because they like and are excited about Zig.

by wolttam

5/31/2026 at 4:52:15 AM

Go is a terribly verbose language.

by vips7L

5/30/2026 at 9:52:58 PM

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

by akazantsev

5/31/2026 at 4:57:50 AM

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

by vips7L

5/31/2026 at 7:20:34 AM

That is the curse of guest languages, see C and C++ as well.

That is why I always say keep with the platform, and why despite my endless rants on C, I keep myself up-to-date in regards to it.

Eventually they always diverge.

by pjmlp

5/31/2026 at 8:24:46 PM

It'll be interesting long term to see where they go with Kotlin. WRT value classes they'll probably introduce something like @JvmValue like the did with @JvmRecord when data classes diverged from Java records.

by vips7L

5/30/2026 at 10:24:14 PM

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

by bpavuk

5/30/2026 at 11:14:20 PM

> Kotlin <-> Java interop is a totally optional topic you could have skipped over

This is the same place F# has been stuck in. It’s a great language on its own, but you can’t just use F#. Every F# must also do C# interop. It’s too 100% optional in theory, but never in practice. The best CLR/JVM libraries for anything are Java/C# ones. You need to interop with them to develop practical Kotlin/F# applications. You can limit yourself to the Kotlin/F# ones, but then you’re artificially limiting yourself to experimental libraries at best. You will find yourself needing a charting library, a DNS library, an SMTP library, an AWS SDK or a rabbitmq SDK. The best ones are gonna be Java/C#. Yes, you can always find a random GitHub repo for a “Kotlin-native X”, but the Java X library is a thousand times more mature, stable, performant, feature rich, etc. Same problem with F#. And the “glue” code is so “straight forward”, why would any one bother?

by eddythompson80

5/31/2026 at 6:17:47 AM

I have quite literally never had to do Java interop in my Kotlin work. Do you have an example?

In contrast, your statement about F# strikes me as mostly true - albeit my interop was always the other way around (consuming F# code from C#).

by demilicious

5/31/2026 at 7:22:18 AM

Calling Koltin co-routines directly from Java code, as an example.

There is a reason Android team has Java friendly guidelines.

by pjmlp

5/31/2026 at 1:18:49 PM

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.

by vanviegen

5/31/2026 at 12:54:44 AM

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.

by dapperdrake

5/30/2026 at 9:18:01 PM

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.

by alexboehm

5/31/2026 at 7:45:13 AM

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

by lukaslalinsky

5/30/2026 at 10:04:50 PM

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

by dnautics

5/30/2026 at 10:27:49 PM

`@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

by bpavuk

5/30/2026 at 11:14:17 PM

i would have guessed easier, since it makes c modules and zig modules ~indistinguishable?

by dnautics

5/30/2026 at 8:40:23 PM

> Zig-native immediate-mode

dvui?

by gliptic

5/30/2026 at 10:37:36 PM

many thanks, will look into that...

by bpavuk

5/31/2026 at 2:18:35 AM

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

by Mawr

5/31/2026 at 8:12:06 AM

> 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

by bpavuk

5/31/2026 at 2:43:11 AM

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

by spease

5/31/2026 at 1:06:00 PM

No? The conventional engineering wisdom has always been: pick two out of fast, cheap, or good.

And technological improvements don't remove these tradeoffs. You still have to balance tradeoffs. The best thing you could do is have a mix of technologies that choose different tradeoffs. A single technology (zig) won't do.

by tovej

5/30/2026 at 9:13:35 PM

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

by onlyrealcuzzo

5/30/2026 at 10:03:48 PM

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.

by keithasaurus

5/30/2026 at 10:19:04 PM

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.

by onlyrealcuzzo

5/30/2026 at 11:32:57 PM

Yeah, concurrency in blorp doesn't allow shared mutable references, so deadlocks aren't really a concern. Otherwise it's meant to be simple-ish -- virtual threads, channels, no async/await. Pure functions allow safe parallelism naturally, so that's fairly straightforward, though the API is still incomplete, for example the "Parallel" section here: https://blorp-lang.org/docs/lists/. It's still under heavy development (working on it right now).

What are the over-arching goals of your language?

by keithasaurus

5/30/2026 at 11:42:30 PM

Right on.

1) I want to minimize global complexity, which by definition maximizes local reasoning.

2) I want to make the vast majority of bugs simply unrepresentable - taking it past Rust, and even past Pony - WHILE allowing shared mutable memory, but without requiring a PhD to use.

The goal is in EASY mode, it's barely harder to use than Ruby or Python (just the occasional pedant compiler error that has automatic options to fix itself most of the time). You don't even have to supply types or compile. It has a REPL, etc.

When you bump to DEFAULT mode and then to STRICT mode, all the annotation is automatic - your code just might look "ugly" if you like having no types anywhere etc.

But DEFAULT & STRICT mode give people and LLMs everything they need to know to understand the effects of an individual function.

by onlyrealcuzzo

5/30/2026 at 11:54:07 PM

I have some similar goals. Have you considered leaning more into inference than gradual typing? One pattern I like is allowing the compiler to develop a more complex mental model, but keeping it straightforward for users -- you can do that with inference, ownership, purity, effect types, etc. What I actually think is really tantalizing is using tooling to fill in some of those gaps -- for instance, the editor could know types, required capabilities etc, without the user ever needing to type anything, but when the user needs it, they can find it, query it, test against it.

by keithasaurus

5/31/2026 at 1:15:28 AM

Cool - it sounds pretty similar. It's interesting that it looks so different. I'll have to investigate more.

WRT to inference, yes. I infer everything in EASY mode.

And the compiler give the user autofix via choice when a type is ambiguous (I don't default to huge union types - I assume no one wants to do that and make them choose a type - may potentially allow AutoUnion to allow that).

I couldn't tell if you're using affine ownership, but I assume so if you don't have a GC. If they try to create an alias - they get a use after move error, and the compiler tells them they need to either COPY (auto-fix) or create a RefCount (usually auto-fix) - they pick.

by onlyrealcuzzo

5/31/2026 at 6:51:17 AM

No, blorp doesn't use affine types (one or zero uses). In blorp, ownership is not explicitly controlled by users at all, so it's opaque. Under the hood, it's perceus for compile-time ownership and borrowing and automatic reference counting with copy-on-write optimizations for the runtime. This is made reasonably easy for the compiler to reason about in blorp because semantically it doesn't _really_ have in-place mutation -- `var` really means "re-bindable" to a new value; and then under the hood we'll mutate in place where we can.

by keithasaurus

5/31/2026 at 12:40:26 PM

Interesting.

How do you prevent data races in concurrent code?

Or do you not allow shared mutable memory?

by onlyrealcuzzo

5/31/2026 at 2:36:39 PM

Yeah, no shared mutable memory; coordination is done via channels.

by keithasaurus

5/31/2026 at 4:37:57 PM

Awesome.

If you want some feedback, I'd recommend putting some concurrent benchmarks on your home page (and if you have some already - I'd clearly separate them).

When I originally scanned it, I just assumed this was another predominately sequential language with no good concurrency story.

If you're actually competitive with Rust/Tokio/Crossbeam and Go on the most common concurrent patterns, then you've got a really compelling project!

I suspect if you don't cherry-pick benchmarks, you're going to run into some performance problems with not allowing shared mutable memory - though maybe you can avoid most of that if you have some type of built-in actor pattern.

But if you're actually competitive across the board with Go & Rust/Tokio/Crossbeam - I'd love to take a deeper look, because that is NOT easy to accomplish.

I didn't see any of that from a cursory look at the language, though.

by onlyrealcuzzo

5/31/2026 at 7:08:45 AM

How is compiling to zig? I considered doing it but chose C instead because of how much zig is still changing. I've considered using it's C compiler for targeting multiple platforms locally.

by keithasaurus

5/31/2026 at 12:38:54 PM

I would HIGHLY recommend transpiling to Zig.

Comptime is very powerful and awesome to use for a transpilation target.

Also, Io and how Zig handles allocation and gives you full control of the allocator make it super easy to do things you probably want to do in your language.

by onlyrealcuzzo

5/30/2026 at 7:43:15 PM

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

by librasteve

5/30/2026 at 11:07:07 PM

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.

by GuB-42

5/31/2026 at 11:05:57 AM

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!

by librasteve

5/31/2026 at 2:48:12 AM

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

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

by spease

5/31/2026 at 7:24:30 AM

Does not help the regulator posts on HN about having rewriten known projects into Rust, and since we are on a Zig thread, Bun.

by pjmlp

5/31/2026 at 2:06:52 PM

Those rewrites happen because someone was interested in making them happen (often the maintainer). The meme is that evangelists will constantly advocate to you that your project should be rewritten.

by surajrmal

5/31/2026 at 6:08:06 PM

I hardly see a difference, that is how evangelism works.

by pjmlp

5/30/2026 at 11:29:21 PM

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!

by AndyKelley

5/31/2026 at 10:43:23 AM

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?

by librasteve

5/30/2026 at 8:12:08 PM

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

by nagaiaida

5/31/2026 at 10:59:32 AM

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

by librasteve

5/30/2026 at 5:57:20 PM

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

by teabee89

5/30/2026 at 6:42:14 PM

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?

by derefr

5/31/2026 at 4:09:06 PM

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

by wsve

5/31/2026 at 12:56:21 AM

Research "cl:define-compiler-macro".

It has been done before.

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

by dapperdrake

5/30/2026 at 7:39:30 PM

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

by ksec

5/31/2026 at 7:39:07 AM

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

by brabel

5/30/2026 at 8:17:24 PM

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

by mgrandl

5/31/2026 at 7:26:43 AM

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

by pjmlp

5/31/2026 at 9:05:15 AM

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.

by flohofwoe

5/31/2026 at 10:58:15 AM

Depends on which compilation pipeline, I would say.

by pjmlp

5/31/2026 at 9:58:38 AM

I mean Nim just compiles to C or C++, so it's bound to be slower

by cenamus

5/30/2026 at 11:33:23 PM

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.

by ozgrakkurt

5/31/2026 at 12:09:18 AM

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

by mattgrice

5/31/2026 at 7:28:07 AM

That hack is because of C.

Definitely true when using VC++ with C++20 modules and MSBuild.

It also helps not compiling everything from source as many UNIX folks do.

by pjmlp

5/31/2026 at 9:10:17 AM

> Definitely true when using VC++ with C++20 modules and MSBuild.

Lol, sorry, but as soon as MSBuild is involved the compiler can be infinitely fast and you'd still need to be waiting for the build. Also the main problem of MSVC is the slow linker, and that isn't fixed by C++ modules. This is also the first time I'm hearing that C++ modules actually help with compilation speed in real world projects - the best I've heard so far is that they're a bit faster than precompiled header but not by much, which simply isn't good enough for typical C++ projects.

by flohofwoe

5/31/2026 at 10:57:38 AM

Follow engineering principles and actually test it.

The company behind Cadifra UML Editor is quite happy with their migration, the owner keeps posting about their modules experience on Reddit C++.

Microsoft also has CppCon talks on the matter.

All my C++ hobby projects use modules, as I only care about VC++.

by pjmlp

5/31/2026 at 12:57:23 AM

This has drastically changed with "recent developments".

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

by dapperdrake

5/31/2026 at 3:07:31 PM

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

by setheron

5/30/2026 at 10:58:28 PM

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

by androiddrew

5/31/2026 at 2:25:39 PM

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.

by up2isomorphism

5/30/2026 at 6:21:37 PM

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?

by quikoa

5/30/2026 at 8:42:46 PM

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?

by c0rruptbytes

5/30/2026 at 8:47:35 PM

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.

by agluszak

5/30/2026 at 8:48:14 PM

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

thank you, this helps!

by c0rruptbytes

5/31/2026 at 5:51:11 AM

I used to think Zig was the new C, but its different enough to be its own category, imho. For an actually "new" C, try https://c3-lang.org/.

by donpdonp

5/30/2026 at 11:19:52 PM

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

by Ygg2

5/31/2026 at 1:57:48 AM

"technically" usually means something like "strictly", not "by a completely different metric". work takes time. zig has had a decade of work put into it.

by peesem

5/31/2026 at 2:09:16 AM

Technically means according to a strict, often legal definition.

The strict definition being we don't count developments that happened before version 1.

Like when we talk about Rust, we don't mention the virtual threads or GC or the @ symbol for GC references. Even though those all happened during its development.

by Ygg2

5/31/2026 at 4:25:47 PM

and when people talk about zig, they don't usually mention that zig used to have goto, casting syntax like `T(val)`, a rule that said you couldn't pass containers by value, language-level async, some truly awful syntax for what is now `try` and other operators, etc. both languages took time and work to realize that these features were not for them. very strange to deny that.

also, nitpick: they said zig has been around for ten years. this is, strictly, correct. the zig project has existed for ten years, just like how rust has existed for about 20, now. a project still exists if it is pre-1.0. nobody was talking about versions before you.

by peesem

5/31/2026 at 2:06:17 PM

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.

by epolanski

5/31/2026 at 2:33:08 PM

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.

by pjmlp

5/30/2026 at 6:11:14 PM

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

by bcardarella

5/30/2026 at 6:18:42 PM

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/

by kristoff_it

5/30/2026 at 6:22:25 PM

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

by bcardarella

5/30/2026 at 7:15:52 PM

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

by cafebabbe

5/30/2026 at 6:19:50 PM

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

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

by mi_lk

5/30/2026 at 6:19:57 PM

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

by dzbarsky

5/30/2026 at 10:08:00 PM

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

by dnautics

5/30/2026 at 11:46:29 PM

They're probably refering to their strict "No LLM / No AI" policy: https://codeberg.org/ziglang/zig/src/branch/master/README.md...

which applies to contributing to the Zig project.

The "contributor poker" blog post should probably be a required reading to understand where it comes from: https://kristoff.it/blog/contributor-poker-and-ai/

"Anti-AI stance" is painting it with too broad of a brush. You're definitely not breaching any CoC or whatever by using AI for your Zig projects.

by mihaelm

5/31/2026 at 3:25:57 PM

> too broad of a brush

yes, that was my point. as domeone who uses ai extensively to write zig (and someone who has made very small non-AI cobtributions to zig in the past), rejecting ai is currently a strategically good decision for core zig.

by dnautics

5/31/2026 at 2:07:26 PM

And the largest Zig projects all make use of AI assistance to build software.

by epolanski

5/31/2026 at 3:25:10 PM

tigerbeetle does not, but the others do.

by dnautics

5/31/2026 at 7:21:13 PM

Yes, of course, I'm sure no developer there ever uses ai assistance...

by epolanski