this post was submitted on 04 Feb 2025
8 points (100.0% liked)

Zig Programming Language

178 readers
5 users here now

A lemm.ee community for Zig!

founded 1 year ago
MODERATORS
 

Roc's compiler is being rewritten in Zig primarily due to significantly faster compile times, which have been a major pain point in Rust.

Zig's allocator-based memory management, better tooling for static binaries, and built-in support for optimization techniques (like struct-of-arrays and bit-packing) align better with Roc’s needs.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 week ago (3 children)

Me: oh, this is going to be a fun fad.

Did I mention compile times? I'll reiterate: compile times are a huge deal.

When I look through AUR for a project that fulfills a need I have, I look for three things, more or less in this order:

  • Implementation language
  • Last update to the project
  • Feature set

The third point assumes I've already filtered for projects that satisfy my minimum requirements. For the first my filter excludes Haskell, Node/Electron, and Rust unless there's a binary package for the Rust project. I also only accept Python in extreme cases, as trying to keep Python programs running through software package updates of starting to become a pain. I prefer either Go, but Rust-bin, Zig, or C are all fine. I haven't seen enough Nim or Odin projects to really have an opinion.

But I've started to hard filter out non-binary Rust projects because I've recently noticed that - in any upgrade - most of the time is spent compiling Rust projects. Updates of a few dozen projects can literally turn what would normally be 15 or 20 minutes into multiple-hour upgrades. And these aren't, like, Firefox-size projects; they're mostly little CLI tools.

I really like Haskell and used to maintain some software projects in it myself, but GHC compile times are absurd, and I now won't install anything Haskell unless it's a -bin, which (for some reason) almost no Haskell projects provide. I suspect it's because GHC tends to use dynamic linking and so dependency management is hellish, but it could also honestly be because the project maintainers can't afford the compute for CI for multiple target architectures -- it's that bad.

I say all of this about Haskell because - as a user - I see the same trend in my own filtering habits: as Rust projects begin to make software updates more painfully slow, it's becoming a dominating deciding factor when choosing between projects.

I don't particularly care for Rust, as a language, but I like the binaries it produces and if the compile times didn't suck so much it'd be in the "plus" column. But Rust compile times seem to be getting worse, not better, and I honestly think the Rust team should drop everything else for a while and look into addressing this degrading situation.

It just occurred to me that I could probably generate a decent graph illustrating this rant based on data in /var/log/pacman.log. I think I have today's project.

[–] [email protected] 3 points 1 week ago (2 children)

looks over Pascal's very fast, single-pass compiler

[–] [email protected] 2 points 1 week ago

Good memories of Turbo Pascal 5.5 ;)

load more comments (1 replies)
load more comments (1 replies)