Nice idea! I was only thinking about "how could I make Zig more efficient", I didn't even consider making Rust more similar to Zig.
I added a Python script wrapping rustc which serializes all rustc invocations for bun_* crates; you can find the recoridng at [1]. Turns out it only increased the build by 1 minute! So clearly my intuitition that it was just crate parallelism was not correct.
One more confounding factor though is that rustc is parallelised while Zig's compiler is not (yet). So it's still possible that might be the reason.
this! - the reason Zig defaults to one semantic analysis thread is due to current (to be improved) limitations; some ideas for Zig also will require one compilation unit - the restricted function pointers proposal being a good example: https://github.com/ziglang/zig/issues/23367
The bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast... YET the builds were no longer deterministic, which is a hard requirement for lots of things. More effort will need to be spent here than naively adding a thread pool. Hopefully Zig's Sema.zig gets faster, but Rust is also super slow at compiling and needs to improve. Oh - one last thing to note, Zig has very fast debug compilation and incremental compilation, it's a real nice thing to work with that you simply can't approach in most other languages right now.
> The bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast...
I actually collected a build with multi-threading turned on [1]. It helped quite a bit, cutting the Zig object time from 7m49s to 4m05s. But because of the reason you mentioned (and the post was already so long!) I decided not to bring it up.
> Oh - one last thing to note, Zig has very fast debug compilation and incremental compilation, it's a real nice thing to work with that you simply can't approach in most other languages right now.
Yes, in fact I also tested just running bun run build / bun run build:release and captured traces for both! The clean release build took 3m36s for Zig versus 5m50s for Rust [2][3]. Clean debug was closer: 3m07s versus 3m27s [4][5].
I also tried incremental debug builds: adding a comment to output.zig / output.rs took 48.6s / 65.4s to rebuild. Ordinary developer builds certainly gave a different picture from CI.
Yes indeed, that will be a much better road to a durable, maintainable, secure and agile product than focusing on product goals in a higher level language with a framework.
When will we start using LLMs to write my web backend directly in UEFI and assembler? (Although uefi is an OS, so maybe more fair to exit the boot services)
This is a genuinely interesting topic, and as we say in the blog post:
> Together, we’re building a comprehensive package registry to serve the Swift community’s evolving needs.
The great thing about a registry is that it doesn't care where the original source is hosted. We will be moving away from that model completely as we work towards this.
I’m really interested how you got these numbers. Using some of the daycare providers in our most expensive city (Amsterdam) with an obscene collective income (250k) with 5 full days of daycare (which not many parents even want) I get net 1300 per child.
For 3 days with more normal incomes it is closer to 700-800 euros
Mollie B.V. is licensed and registered as an electronic money institution with the Dutch Central Bank (relationship number: F0038). Mollie UK Ltd is licensed and registered with the Financial Conduct Authority as a payment institution in the UK (FRN: 977968).
reply