kristoff_it

We used to have a version of ArrayList that bundled an allocator in the stdlib, we removed it because our experience having written Zig code for a few years led us to reach for the allocator-less variant almost always.

One aspect your argument is missing is that if you are juggling many ArrayLists, having each bundle its own copy of the allocator (instead of storing it just once) means wasting 16 bytes per ArrayList. The allocator-less variant is simply more flexible in that regard.

In the Zig core team we have the right to decide how we want to conduct the development of our open source project, and that decision is based in good part on the same factors presented in this post, which are significantly more important than validating your FOMO.

Likewise, in your projects you can do whatever you want. That was true before LLMs and is just as true now. Thinking otherwise is a weird form of open source kleptomania induced by listening to too many techfluencers, in my opinion :^)

In my open source projects I decide which tasks I'm willing to delegate and which tasks I want to take on myself and, of those that I'm willing to delegate, I decide who gets to take on them. This includes the fact that, even if the quickest way to get something done is to delegate it to an LLM, if I want to do it myself for personal growth, I will still do it myself.

Conversely, it should go without saying that if I want to use LLMs, that's my right and whoever wants to complain can go fork (the repo) themselves.

(reposting my comment from lobsters)

For anybody reading, the project tracks new Zig to get all the new async I/O goodies but was hit by some regressions in Zig's translate-c because it recently became fully independent from LLVM.

Other contributors and I took this as an opportunity to contribute some fixes to translate-c and in my case I also switched for a bit to my other projects, mainly https://zine-ssg.io, which I had neglected for a few months while going all-in on awebo.

I plan to resume development of awebo in a month or two, I just want to leave Zine in a good spot before switching again (I have a had time paging between different projects too often and prefer doing continuous work for a while before switching back).

Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.

The people who originally worked on Bun themselves would disagree with your point (but their situation was based on the premise that they did not take the steps required to leverage incremental compilation): https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...

And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.

To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along.

To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.

That is a 100% on point analysis, there was a lot of hype around Bun since the beginning when it was an invite only project. Arguably that same interest is what got Jarred VC funding in the first place.

Note that usage and public interest are not the same quantity, people also care about the potential of a project.

> Writing memory safe code in unsafe languages requires global reasoning

If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never.

If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.

Thanks, yeah Andrew gave a pretty good interview to the JetBrains people recently https://www.youtube.com/watch?v=iqddnwKF8HQ

I think you will be surprised by how many developers do not have this same list of priorities (or in that order) when developing software.

I posted this link at the same time when I posted it to Lobsters (https://lobste.rs/s/g6lkw1/my_software_north_star) 3 days ago, but it didn't get on the front page. Seeing that the submission time has been reset, I imagine it was given a second chance by HN curators (it's a known process), but that doesn't mean free upvotes, it's just that some people resonate with the thinking.

The truth is a bit of everything, bun being a messy codebase written primarily with "move fast and break things" in mind, cultural divergence between Bun and the Zig community, and also hiring issues. People maybe forgot but Jarred at some point caused a bunch of drama when he tweeted that working at Bun is not for people that value life/work balance, which went viral and caused an uproar. Must not have been super easy to hire from the Zig community after that, and in fact once Bun got acquired by Anthropic, it was pretty much Jarred and Claude doing all the work on the codebase. Pivoting to Rust is probably at least in part a way to reset the clock on those hiring interactions.

> I imagine it's a difficult time to be a Zig developer.

In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into threads about Zig to remark how immoral it is to use Zig, and now LLM shovel sellers are telling everybody that the only way forward is to become efficient at consuming tokens.

But it's actually not that bad.

The Zig community is growing pretty well, useful software is being written in Zig, and the advantages that Zig brings are still valid whether you hand-code or use LLMs (e.g. cross-compilation of C/C++ code).

That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post is doing, won't make you create better software.

If Rust helps you get all the way to correctness, then great, but that blog post was insane.

trying to make good software :^)

That is the opposite of what's going on, read this https://kristoff.it/blog/contributor-poker-and-ai/

The problem statement is clear to everybody.

> For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.

The solution, IMO, is a strictly worse version than what we chose in the Zig project (banning LLM contributions).

> AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.

Things that worry me about this choice:

- open source is a tough business and you need to leverage the good things about it to make it worth doing. contributors bring in a huge amount of value that they offer you essentially for free (see contributor poker: https://kristoff.it/blog/contributor-poker-and-ai/), on top of being a hugely valuable recruitment funnel. They're rejecting all of that, which seems insane to me.

- one could argue that LLMs could fill that gap but, first of all they could have just banned LLM usage only in PRs from untrusted contributors, and second even the best LLM: 1. is a cost, not just free value, and the price of tokens is increasing 2. the code has to be reviewed anyway, unless you think that just passing tests is good enough for a browser 3. ultimately can't become a trusted core contributor able of taking ownership of a part of the codebase

- removing the influx of code that comes from PRs means that over time the whole project will have a small number of contributors that own all the code, making it easier for the project to do a license rugpull. when copyright ownership is well distributed this kind of thing is harder to pull off.

Overall, this is not good in my opinion. They're making open source a more problematic business model for them than it has to be, while at the same time making it harder to recruit more core contributors, as the code ownership coalesces to small group of people.

This is an obvious recipe for disaster (a rugpull), and I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors are playing a mean game of Secret Hitler. I guess only time will tell.

Another Zig GUI project that people might be interested in is DVUI:

https://github.com/david-vanderson/dvui

It's not Future.await that is special per se, it's that it (Future.await) will have in it somewhere either in its body or in another function that it calls in turn, a use of `suspend` (using old Zig syntax).

`suspend` is the keyword that best fits your description (you can think of it as being closely related to `yield` in other languages), and it's kind of a lower-level primitive compared to async/await.

This also means that, according to our plans, Zig will have to propagate "stackless-ness" upwards in the call chain while analyzing the code (thus making Future.await not special per-se).

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/

> If so, does that mean that every function in zig is a stackless coroutine?

No and yes.

If you're using Io.Threaded, then the concurrency model is multithreading and calling Future.await will block your thread on a OS futex.

If you're using Io.Evented, then the concurrency model is green threads / fibers and calling Future.await will suspend the current green thread by yielding (swapping CPU state with another fiber).

Zig currently does not support stackless coroutines so today you can't have that, but we used to have them (pre self-hosted compiler), and there's an accepted proposal to bring them back, in which case any function that calls await, or that otherwise has a suspension point, would have to be transformed into a stackless coroutine by the compiler, yes. The plan is for that to happen transparently without requiring an `async` annotation in the function signature, like we already did in the past.

This is an old post of mine that explains how that worked at a high level: https://kristoff.it/blog/zig-colorblind-async-await/