Loris Cro ⚡

Asynchrony is not Concurrency kristoff.it/blog/asynchron…

well it's been fun rolling in the mud, I'm logging off to do actually relevant stuff, see you all next drama

People often get this wrong: But per systems thinking, correctness is not a { language, static allocation, testing, etc. } problem. Correctness is a design problem.

Fork your dependencies, trim them to only your use case, never update unless it breaks for your users. I’ve been vocal about this for 10+ years. I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored). If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies. If you dont see anything compelling, dont update! I remember at HashiCorp once in awhile an engineer would try to update a dep or replace a DIY lib with an external one and id always ask “show me the commit we need.” Dont update for the sake of it. Feeling pretty swell about this mentality with all the supply chain attacks happening.

that blog post is taking a while to come out, I guess some things still require some good hammering to be made look good enough :^)

@melhindiCS @TigerBeetleDB @captainhorst @georg_kreuzmayr @Tobias__Ziegler @maxikuschewski wait there's a whole Munich office??

Great visit to @TigerBeetleDB’s Munich office yesterday. Inspiring discussions on distributed systems, from failure detection to performance testing. Nice to see @TigerBeetleDB join Munich’s DB community. Thanks @captainhorst @georg_kreuzmayr @Tobias__Ziegler @maxikuschewski

Which loop is more likely to 10x your team’s design/code/test/debug/release/maintenance velocity, but also with mission critical quality, faster performance, more beautiful code, deeper understanding as a 2nd order effect, and lower total cost of ownership?

@_annieversary absolutely! usually at zig days that I attend we do an intro to zig in the morning for people who are interested

@croloris are zig beginners welcome too? ill be in boston around that time and id love to go, but i haven't had much time to play with zig yet

Systems Distributed '26 is getting closer and so is the Zig Day Boston scheduled for the day before (completely free, NO conference ticket required). Come practice your systems thinking and make software you can love with us! RSVP: luma.com/eloljzc0

@bcardarella gh issues are still valid, they get ported to codeberg as needed, so don't worry the plan hasn't changed

@croloris did this issue get migrated over to Codeberg? I cannot find it there github.com/ziglang/zig/is…

@renerocksai @Claude funny thing, node could just lift from Bun the part of the codebase that implements the node API :^) slop for slop might as well, at least they would save some tokens

@croloris Now that bun is rust, would be a great time to vibe-code node to zig to fill the void! @Claude: Port it. Make no mistakes. Stop and tell when 98% tests pass!

I sincerely hope that Node does not plan to vibe-port its entire codebase, regardless of the target language. Node is the only truly open source runtime for JS and I hope that its maintainers will prioritize stability and responsible stewardship of the project, ideally protecting their own version of contributor poker (i.e. guaranteeing that contributors can grow into future maintainers), none of which is helped by vibe-porting the entire codebase in one commit.

That's an apples and oranges comparison, do it with Bun and Node. Node has many open source contributors, a core team, a non profit foundation, and probably enough money to keep going for as long as they're relevant. Bun only has one of these things. Would you really trust Bun more than Node because they got money?

@croloris @tiptenbrink This is pretty nutty from a dollars and cents perspective. If the Q is who is better capitalized for the long haul, Anthropic or the Zig Foundation, I don't know many investors/lenders who would rather bet on the Zig Foundation.

@tiptenbrink yes, not subject to running out of money and having to enshittify / sellout / rugpull the userbase, which is inevitable from VC-funded businesses that don't have a valid business model (which has to both keep the business afloat and provide the promised return to the VC).

@croloris What do you mean with truly open source? Not VC-backed?

The Zig build system is perfectly capable of linking against prebuilt artifacts. "compile from source every time" is a made up idea that maybe works in your circles but that makes no sense in the real world. It's in fact much more common to link against prebuilt system libraries on Linux, than to build everything from source (there's a limited number of distros that do it, and they're famous for being niche options aimed at Linux enthusiasts). On the other hand, without a build system, if you want to fake the convenience of having one, you have to bundle arch X os artifacts... or you can act like x64 Windows is the only target that matters and only upload a single .lib file, like here: github.com/odin-lang/Odin… but that detracts a bit from the general-purposeness of the language, doesn't it? In github.com/allyourcodebase, Zig packages always offer the ability to build from source because it's what gives users the maximum amount of flexibility, as it lets them take advantage of target specific features such as optional instruction set support. And also because it's unfeasible to upload the whole matrix of prebuilt executables that matches all the targets that we intend to support seriously.

@croloris @c_lerno @oxcrowx Binaries are great. The whole "let's compile from source every time" didn't get traction until Linux, due to that being pretty much the only way to get it working on Linux. But guess what? It's not a virtue, it's cope.

Why is Odin keeping binaries and libraries in their repo? One of them is 55 MiB in size. Many others exist.

Sorry that proposal was already rejected. On one hand I share the sentiment, sometimes it would be convenient, but on the other I've started to find it annoying to see in other languages function definitions nested in function bodies for no good reason other than cursor placement convenience. You still have the `struct{ fn foo() {} }.foo` escape hatch. It's not elegant, but I prefer it over the above.

@croloris Lexically scoped anonymous functions please.

Yeah, luckily it's impossible for Anthropic to buy the Zig Software Foundation. Some things in life money alone just can't buy, like a functioning codebase that you understand, and a trust relationship with your users :^)

There were some positives for sure and yes bun did donate to the ZSF, which is appreciated, but the visibility was mostly superficial. The majority of people that discovered Zig through Bun were web devs who quickly became disinterested because Zig is not yet mature enough to offer a comfortable webdev experience. On top of that Bun has also had a variety of other influences on the community (eg by hiring from it), not all of which were positives (but that's some dirty laundry I'm not going to air on twitter). Of course going forward more companies will use Zig and do whatever with it, but Zig is still small enough that these things do make a difference.

but you'll have this issue as long as zig is getting more ubiquitous. there will be more programs written in zig, and thus there will be more zig programs with bugs (that lead to finger-pointing). until zig becomes a mainstream language, at least. i would not have been particularly interested in zig if it wasn't for bun, simply because i wouldn't have heard as much about it. at least from my POV, bun has been a massive boon to the success of zig. not to mention that they offered contributions and donated quite a bit of money. it saddens me to see that you're essentially wishing for all that to not have happened

I wonder if GPT5.5 would have done a better job at translating Bun. Now Bun not only has a hard dependency on token expenditure to be maintained, but it's also locked into one model brand, while the competition can choose whichever model happens to be the best at the time.

@mikkurogue I can't think of any. The whole idea seems incompatible with what we're doing.

@croloris Would there even be anyone who you guys would be willing to work with that acquires Zig? Like on the same ideals and wavelength etc Out of the plethora of companies and foundations zig is the most unique and probably most outspoken and relatable

@dduxAdventure in the past devs would also be worried that by not having a big tech patron Zig would never go anywhere, but that's the shallow part of trust, once you break that barrier, it doesn't matter anymore no idea if/how that applies outside of programming languages

@croloris maybe with devs, but I've had deals stall with enterprise customers because I hadn't taken on VC money... some companies equate money with trust...

@c_lerno @oxcrowx ah yes the enjoyment of committing windows only binaries to the repo

@croloris @oxcrowx You mean ”enjoy”. Not all languages want to be like Zig and depend on recompiling everything from scratch all of the time.

@antirez read the blog post salvatore, this whole point is irrelevant

@croloris AI assisted contributions are not all the same. There are AI coded stuff that are better than what the programmer could have done otherwise and there is complete AI trash. Flattening this complex reality I believe is not sustainable in the long run by any project.

The Zig compiler project rejects AI contributions for very concrete reasons. - The contributor pipeline is a core aspect of our business model and produces value FAR BEYOND the code. Breaking it is an existential threat to Zig. kristoff.it/blog/contribut… - For some projects it's a problem to rely on vibecoded infrastructure. Some have learned this the hard way with Bun recently. Zig is general purpose programming language for building critical infrastructure and we want to give maximum freedom to our users. See quoted message.