Zig: Build System Reworked

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

by tosh • 2 months ago

362 245 2 months ago

ziglang.org

epolanski4• 2 months ago

This sounds like great news, Zig's compilation times are already terrific and this is going to only make them better.

dmit6• 2 months ago

Zig's compilation times are already terrific

In my experience, this (for now) is mostly aspirational. It's obviously a major goal, and there are clear milestones outlined on how to achieve it, but in practice the initial compile of an empty project or the excruciating pause when you `direnv allow` and ZLS needs to be (re)built are not what I'd describe as "terrific".

epolanski4• 2 months ago

Maybe you're right, but how many other system programming languages toolchains give you sub 50ms recompilations across millions of LoC?

schaefer• 2 months ago

(re)built are not what I'd describe as "terrific".

It sounds like you are a strong candidate to try out the new improvements mentioned in this devlog and see what benefits you can get for yourself.

wffurr• 2 months ago

Compared to Rust or C++?

pjmlp7• 2 months ago

Yes, compilation speeds of the 90's are slowly making a return, thankfully.

bbkane2• 2 months ago

I thank Go for this. Go's compilation times seemed to inspire other language devs

ozgrakkurt3• 2 months ago

Just creating a file with dummy test like

if (2 * 2 != 5) { @panic("fail"); }

And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer. It also keeps taking the same amount of time every time I do it when I modify that file. Using 0.16 (or master) version so my toolchain isn't old and I'm on linux.

Zig is super nice to use as a language but the compiler/stdlib isn't developed conservatively enough imo.

You may not run into an issue like this when starting out with hello world but you will want to run optimized binaries for fuzz testing or benchmarking. And then it becomes super annoying considering you might be compiling a relatively small amount of code.

Just for comparison, imo Zig is a much better language than these other languages, but if you did something like this in Rust/C++/C etc. this kind of issues basically doesn't ever happen. Assuming clang/gcc/ninja etc. usage for C/C++.

I am able to use Ninja/Python/clang for configuring/building (-O2 or -O3)/testing ~10k loc C++ project in 200ms on the same computer for example.

ozgrakkurt3• 2 months ago

Also another point. I have some zig projects from couple of months back and they all have build.zig/build.zig.zon. I tried to copy that to the new dummy project I did and of course the API changed and that is broken now (just 15 lines of build.zig code).

This kind of thing just feels unacceptable considering I don't really see ANY improvement on the issues I had from back then.

Also had a similar baffling experience when I last tried to come back to writing Zig. The std.time.Instant or similar API that also exists in rust and most other languages was move to the new Io interface and they also completely removed that std.time.Instant code.

Overall it feels like people developing the tool don't respect the people using the tool. C++ or even Rust are much less enjoyable languages to write compared to Zig so it is really sad that it is not possible to actually use Zig for me.

defen3• 2 months ago

Just creating a file with dummy test like
if (2 * 2 != 5) { @panic("fail"); }
And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer.

What kind of computer are you on? I just ran that test (latest master build, first run):

   ~ % time zig test file.zig -OReleaseSafe
   file.zig:1:17: error: expected type expression, found '{'
   if (2 * 2 != 5) { @panic("fail"); }
                ^
   zig test file.zig -OReleaseSafe  0.03s user 0.44s system 505% cpu 0.094 total

Granted I'm on an M4 Mac but I wouldn't expect another system to be 20x slower.

portly2• 2 months ago

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly".

For me it is now the go-to "tinker in my garage" language.

ACCount375• 2 months ago

Is it really that good?

My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

norman784• 2 months ago

Zig is low level, so it will certainly not replace your python usage, it is more like a modern C than anything else. There’s a video of a recent interview with Andrew Kelley, if you want to watch it to understand better what Zig is for, it’s on Jetbrains YouTube channel.

dmit6• 2 months ago

Have you ever thought "Ugh, this bit of Python code is running much slower than I expected on my computer. Wonder if anyone has written a native library for this"? That's probably the closest use case for someone who matches your description -- a language that is much more ergonomic, much more 'modern' feeling (in all the good ways), while still extremely compatible with C.

As for the language itself, it's going to be more verbose than your Python code. Cons: you'll have to spell out a lot of things that you thought were obvious assumptions. Pros: you will be able to look at a page of code and know with a great degree of certainty that there are no hidden gotchas. No monkey patching, no __init__. Basically, it just does what it says on the tin.

And finally, about the std lib and batteries: there's HTTP(S), compression algorithms, hash algorithms, RNG, I/O, the basic data structures you'd expect, JSON. Third-party libraries, if you choose not to vendor, are handled by including the repository url in a file (also automated by a CLI command), and then adding it to the build script (not automated). The `zig` command handles fetching and ensuring sanity, but otherwise assume a bit of elbow grease will need to be involved.

portly2• 2 months ago

I like that you have more freedom. You can play around with some idea but once you want to do something "serious" you can break into it directly. I start simple but sometimes blip into some performance obsession and I find Zig allows that.

miki1232112• 2 months ago

And not only that, if you're doing something in Python, somebody has done it before. Maybe not this exact thing, but something close enough to it. LLMs know it, Stackoverflow knows it, whatever esoteric protocol or file format you're trying to interact with, somebody wrote a library for it in the Python 2 days and has ironed out all the bugs since.

There's no other language quite like Python in this regard. Typescript is a close second, but the lack of metaprogramming facilities, no access to the type annotations at runtime, and the lack of operator overloading make some things needlessly complicated and uglier than they have any right to be.

dtj1123• 2 months ago

The only language I've historically been able to claim to know without feeling like I'm straight up lying has been Python, and having got past my first maybe 1000 lines of Zig I can say pretty confidently that whatever magic makes Python feel comfortable to write, Zig has too.

It requires more of you in some ways, notably that you have to understand the basics of memory management and the behaviour of the stack, but so far I've found the affordances that the language provides for handling this stuff feel very intuitive.

The only sharp edges I've felt so far have been the sometimes hard to guess locations of things in the standard library, and the permenant anxiety that arises from knowing I'm going to be a few more versions behind the current release with every month that passes.

flossly• 2 months ago

You both like different types of tinkering.

Some people put a generator on a tesla cybertruck and call that garage tinkering.

Some people make a go-cart out of a lawnmower and call that garage tinkering.

The first is the "batteries included Python" tinkering, the second is the "low level Zig" tinkering.

jasdfasd8• 2 months ago

Crazy flexing a gateway programming language that everyone and their chachi knows.

FpUser• 2 months ago

I once had to write software that would go through whole bunch of PHP code (more than 5000 files), parse / discover certain patterns and write report with proposed fixes or same but with the fixes applied.

For whatever reasons I had to do it in Python. It was total nightmare to debug as the execution speed in debug mode was insanely slow.

I could've written it in C++ in exactly the same time and not to have any of the performance problems.

trueno2• 2 months ago

took me a minute but once i started tinkering with compiled outputs and not dealing with runtimes and venvs my ability to tinker went super crazy. being able to pass something off to my vps with no dependencies if i was tinkering with something hosted was fantastic, or sharing a sidequest with a coworker that's buttoned up and ready to go with no additional environment setup for them

lll-o-lll• 2 months ago

“Tinker in my garage” for low level things. If I’m playing around with a custom layer 2 protocol, python is not my language of choice.

Basically, if what you are tinkering needs precise control over the bits and bytes, Zig (or C) are designed for it.

OtomotO• 2 months ago

That's so funny.

At university we didn't use Python, but mostly Java, C++, C a bit of Haskell and some even more esoteric ones.

Sure thing I got exposed to Python, but to this day, I don't like it.

All that whitespace typing just kills me xD

I am not normally someone who cares the slightest about Syntax.

I've written Rust, C++, C, C#, JavaScript, TypeScript, Haskell, Kotlin, Scala, PHP, and many, many more in my spare time and being paid to... Yes, I've also been paid to write Python and I use it for some scripts instead of bash occasionally, but boy will I never like Python

tomjen33• 2 months ago

Control. Its a replacement for C that is a lot nicer to work with.

So basically if you either need your Python code to interact with a native library or need more control in a specific place, you can use Zig there.

Zig makes it trivial to control which part of the code e.g allocate memory, so you can guarantee that your rendering or audio loop has no stuttering.

I would still keep Python as the main driver for where dev speed is the most important part.

asibahi• 2 months ago

It’s definitely a great tinkering language but .. eh .. the Zig team and community are extremely opinionated about how to use the language correctly.

mcdonje2• 2 months ago

Not really

0x696C69612• 2 months ago

This has not been my experience.

samuell• 2 months ago

My main issue with this is I expect Mojo to become the go to tinkering language for me.

xyzsparetimexyz5• 2 months ago

But nothing gets in your face how to use the programming language "correctly".

It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me

galangalalgol4• 2 months ago

What do you like to ise those features for?

afirmativ2• 2 months ago

I agree - can't create and toggle between rough code sketches of functions in a source file without these features. It's more than annoying.

saintfire• 2 months ago

The unused variable error drives me insane

If they wanted the release build to be an error I wouldn't care. Having the current solution be "have the editor automatically change code to include or remove the underscore" is so wrong to me. Just invented a problem that needs tooling to modify source code to fix.

defen3• 2 months ago

I love Zig and I am generally very happy with Andrew's benevolent dictatorship and the benefits of having one single smart tasteful person in charge of decisions, but the unused variable one really hurts. My guess is that he's seen what a mess C code can be with regard to warnings and so is just totally unwilling to compromise by adding the concept of warnings to Zig. But if I had one wish about the language, it would be for a command-line flag to disable unused variable errors. So much effort has been put into making iteration fast (all this build system stuff, the custom backend, incremental compilation) and then there's just this giant blocker preventing fast iteration on the editing side.

foresto• 2 months ago

It doesnt let you have unused variables

Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.

It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.

When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.

When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.

What an aggravating, disruptive, and completely unnecessary waste of my time and attention.

I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.

latexr2• 2 months ago

It doesnt let you have unused variables

Andrew Kelly on that:

https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s

Looks like you might be able to get rid of the error easily with annotations.

tomjen33• 2 months ago

You can discard a variable like so:

_ = variable_to_discard

I am sorta unsure why Zig doesn't have multiline comments, but its also not at version 1 yet, so that will likely come, along with better IDE support.

steveharing1• 2 months ago

So i checked the license of this project, can anyone pls clarify what is (Expat) after MIT License

papercrane• 2 months ago

There are a number of licenses that are named MIT that are all similar, but not identical.

The "Expat" here is the MIT license variant. It is referring to the Expat XML parsing library that first used this license.

Usually when projects these days use an MIT license this is the version they use.

maleldil2• 2 months ago

There are different licenses that used to be referred to as "MIT", and explicitly stating "Expat" tells you which one they're referring to (in this case, the "standard" one). This is largely unnecessary, as nearly all mentions of the MIT license refer to this one.

brabel2• 2 months ago

I just upgraded some code to Zig 0.16.0 and I am actually really happy with the results. It impacted A LOT of things, but the changes were actually very good and seems to have set the language for a bright future, especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop!

If you haven't tried Zig since 0.16.0 was released, I highly recommend having a look. The release notes for this release were huge!!

https://ziglang.org/download/0.16.0/release-notes.html

ulbu2• 2 months ago

the “(super) efficient” is not there yet. Io is still dynamic dispatch with multiple layers of indirection. afaik it’s slower than before.

the upcoming releases are expected to provide a solution to this “dispatch is comptime-known, but still dynamic” problem, and drop the loses in efficiency.

rsyring• 2 months ago

The parent seems to be talking about efficient code style, not necessarily performance implementation, as they go on to discuss how it looks.

That is, I think the point was DevX not io performance.

bbkane2• 2 months ago

Hmm in the 2025 talk ( https://youtu.be/f30PceqQWko?si=qZESxMaSyt7fYMfz ), Andrew emphasizes that this approach is more efficient than before- even showing compiled assembly iirc. I guess that was a one-off?

nullpoint420• 2 months ago

Wow that’s gnarly it’s using dynamic dispatch. I mean I get it, but I thought zig was some sort of performance demon.

afirmativ2• 2 months ago

Maybe one day it'd be possible to use these new features, but I find myself using `.use_llvm = true` in my zig builds for stability and lesser tested targets.

tarruda4• 2 months ago

especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop!

I had some trouble understanding how the async/await mechanism works:

  var foo_future = io.async(foo, .{args});
  defer if (foo_future.cancel(io)) |resource| resource.deinit() else |_| {}

  var bar_future = io.async(bar, .{args});
  defer if (bar_future.cancel(io)) |resource| resource.deinit() else |_| {}

  const foo_result = try foo_future.await(io);
  const bar_result = try bar_future.await(io);

My assumption is that calling io.async using an event loop implementation of IO, it will internally start a "task" (or whatever it should be called) and that the future is a handle to it. So far so good.

The part that I don't understand is what happens when you call future.await(io). Will the IO implementation somehow suspend the current function and resume once the future is resolved? If so, does that mean that every function in zig is a stackless coroutine?

jasonjmcghee• 2 months ago

For future reference you can format code on hn with a newline first then indenting each line by 2+ spaces. (Rather than triple tick)

kristoff_it5• 2 months ago

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/

xtreak29• 2 months ago

Bun is moving towards rust but does this also help bun's compilation times?

https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

androiddrew• 2 months ago

I think bun is moving to rust because Anthropic owns it and the devs there like rust. So why would they invest in another implementation? Sad to see a good zig example go, but as soon as Anthropic bought it I wrote the project off.

pylotlight• 2 months ago

Just plain incorrect.. please stop spouting this nonsense, this is not the reason whatsoever.

ulbu2• 2 months ago

bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?

zig is on its way to improving compilation times in its own pace and does so for the benefit of the project and everyone involved, so what is left to care for about bun by anthropic’s past?

jgalt212• 2 months ago

I bet they'll ultimately reverse course on this, or the there will be a bun / zig fork becomes the de facto bun. Despite what the influencers say, I'm convinced you cannot vibe code a conversion this big. It will need a ton of human intervention. And for brand narrative reasons, Anthropic won't commit to such a path.

NewsaHackO4• 2 months ago

bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?

Closing your eyes and pretending a problem does not exist is the a good solution. The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language. This is a nightmare scenario for most companies, and will motivate similar sized companies/project to pick another language that will not require this than to risk using Zig. Also, Zig’s flippant attitude about Bun’s request (among other viewpoints) only further adds to why bigger projects would want to stay away from Zig.

kristoff_it5• 2 months ago

Bun has de-facto refused to use incremental compilation in Zig for ages. It got to the point where Jarred somehow seems to have forgotten that the feature exists.

In any case Bun has already committed to the Rust slop switch, so it doesn't matter anymore.

teabee89• 2 months ago

Somebody should revive the zig version of bun and call it banh as in the vietnamese banh mi sandwich :)

IshKebab3• 2 months ago

Zig has so many compelling features, and I'd even be willing to give up Rust's near-perfect memory safety in some cases. But the one thing that really put me off is string handling. It's just so super tedious. I like being able to finely manage individual string memory allocations, but I really don't want to have to do it all the time. RAII is great; I wish they'd use some light (optional) RAII for strings and containers etc.

metaltyphoon2• 2 months ago

For me it’s string handling, no private, unused variable is compilation error, and having to implement interfaces myself.

nusaru• 2 months ago

Why not use an arena allocator?

IshKebab3• 2 months ago

Tbh I don't know enough Zig to answer that. Can you give an example? E.g. some non-performance-sensitive function that returns a string? In Rust and C++ you can treat the string exactly the same as you would an integer and it's super easy.

In C you have pain. Does the caller allocate a buffer? How does it know how big to make it? Do you have to have separate calls to calculate the required length? Etc. Can Zig work like Rust/C++ and not like C? My impression is that it can't.

onlyrealcuzzo2• 2 months ago

RAII is great; I wish they'd use some light (optional) RAII for strings and containers etc.

Is it not possible to build a wrapper that does this? It seems like it should be.

Arch485• 2 months ago

It is. I definitely agree that strings in Zig can be tedious, but the upside is that if you need it, you can build a string library that does everything you want it to do, in the way you want.

For comparison, while Rust offers a very rich string library, it's also very strict about what you can/cannot do with strings, so if your use case falls outside of that you're out of luck. With Zig, you can pretty easily roll your own and make it do what you want. (and when Zig is post 1.0, I imagine there will be some very nice pre-made string libraries by the community etc.)

nromiun• 2 months ago

Is there any proposed timeline for a stable release? Big features like the recent async IO shows the language is very unstable right now.

bluecalm2• 2 months ago

Andrew's take is "it's ready when it's ready but we hope it's good enough before it's fully ready that you want to use it anyway".

It's different and I like it. You get one shot at it and may just as well get it right in as many areas as possible.

nickmonad• 2 months ago

Yep. He mentioned recently in his JetBrains interview he wants Zig to be a language for the next 50 years. Rushing 1.0 for the sake of signaling to the wider industry today would be actively harmful to that goal.

xydone• 2 months ago

There is no ETA on 1.0, but breakage has followed the pattern of it not really being hard to upgrade to a newer version, as it is very well documented on the version release notes.

araoz3• 2 months ago

writergate was not smooth, a lot of things that moved over to writer (Writer.Allocating for instance) had no documentation and I had to go read the zig source code to figure it out. the docs were just "instead of That use This"

brodo• 2 months ago

nitpick: The language is pretty stable, what changes is the standard library.

xngbuilds• 2 months ago

After watching Andrew Kelley's interview video makes me want to pick up Zig: https://www.youtube.com/watch?v=iqddnwKF8HQ

scuff3d2• 2 months ago

I have a lot of respect for Andrew, and I really enjoy Zig, but God that interview was awful. Andrews answers were fine, but the whole thing felt very sycophantic.

cfiggers• 2 months ago

I didn't get the same impression. I'm curious to know what created that feeling for you. Perhaps I'm turning a blind eye to something or other?

biffgiff• 2 months ago

Why would I want to use this over, say, Node.js and TypeScript?

throwatdem12311• 2 months ago

I suggest you try using Ghostty (written in Zig) for a bit and compare it to another terminal like Hyper (written in JavaScript).

araoz3• 2 months ago

I believe if the work you do fits well with Node & TS, you have no reason to use zig (other than for learning or curiosity). Like, if you don't need every drop of performance, memory layout & control, there's more downsides to using zig. Idk, cruds or "enterprise" stuff or websites don't benefit from zig.

AlienRobot• 2 months ago

What?

You can't run Node on embedded systems, because there isn't enough memory.

A compiled zig program can be only several kilobytes with no depedenencies.

Array access programmed in low-level languages can be optimized with SIMD and parallelization, which will be orders of magnitude faster than the same thing on Javascript. Text processing, image manipulation, video processing, hashing, etc.

There is like infinite reasons to not use Javascript.

yarn_4• 2 months ago

Because they're for two completely different domains?

shirol• 2 months ago

Wish I had this mindset. If I did, I would already have many published apps :(

sourcegrift• 2 months ago

Would someone tell a rust user why they should and should not try zig?

wmedrano2• 2 months ago

Try it if you want full control over every memory and IO operation and "drop". If you hit "goto-definition", you eventually get to see the OS switch statements and syscalls. There's not much magic.

Do not try it if you are scared of memory management and memory leaks.

pron4• 2 months ago

I don't think Rust users are relevant here. It primarily comes down to personal preferences, and since Zig and Rust are so different, some will be drawn to Rust and others to Zig. If you really like a language and it suits your needs, be it Rust or any other, there's no need to look to switch. I think that the audience Zig is aimed at is low-level programmers who haven't taken a liking to Rust, which is the majority of them. Rust isn't very popular among experienced low-level programmers (certainly for a language that old), and I guess Zig is hoping to be more to their liking.

For example, I find Rust to be far too similar to C++, and it shares most of the problems I have with C++ only with much lower adoption. I'm not saying I'm ready to make the switch, but at least Zig offers a different approach that's intriguing to me.

dmit6• 2 months ago

.....Did you just complain about Rust's "lower adoption" compared to C++, immediately following it by "Zig, on the other hand :eyes_emoji:"

DetroitThrow2• 2 months ago

Not working within the bounds of lifetimes, and more ecosystem that doesn't live in the world of lifetimes, gives Zig some of the wonderful dev ergonomics of Rust while making it easier to prototype.

For small, short game dev, or even smaller embedded projects, this ends up being a wonderful way to live as often times you're trying to eke out performance in ways that would require breaking out of whatever type abstractions or using unsafe.

For long-lived systems, for systems that need to have lots of people with various skill levels work on them, for a mature ecosystem, for a language/standard library with stability... You probably don't want to pick Zig right now. Some of these points will change over time with Zig becoming more mature, some won't. Zig will always be super cool to build things in.

As far as most low-level programmers not liking Rust like some other commenters say, lol, lmao even.

insanitybit4• 2 months ago

and should not try zig?

Because it isn't memory safe. I honestly think it's beyond the point of "irresponsible" and well into "negligence" that we're still developing unsafe technologies - people are being harmed by this choice. It's one thing when you have to target specific platforms and maybe Rust wasn't an option or whatever, but the reasons to choose unsafe languages at this point are vanishingly small.

Zig is very cool, I love many aspects of it. I'll never touch it, I'll always advocate against it tbh. I'd probably advocate that software written in languages like Zig be flagged for FEDRAMP and other environments since devs seem to not care unless they're legally barred from making these sorts of choices.

Zakis1• 2 months ago

I completely agree. Zig has a nicer DX no doubt - no fighting the borrow checker etc. But if you are are writing software for other people they don't care about how nice your developer experience is, they only want the software to work correctly - and how can you guarantee that the software you wrote does what you expect it to do if it's not memory safe?

beanjuiceII2• 2 months ago

I'd probably advocate that software written in languages like Zig be flagged for FEDRAMP

this is an insane take

yarn_4• 2 months ago

thank you for this truly deranged comment

smj-edison3• 2 months ago

I can tell you a bit about my own experience, as I've I used Rust for two years, but have now transitioned to Zig. I started working on a modular synthesis engine, and I realized that Javascript wouldn't give me the granular control I needed. So I decided to use Rust. This was my first foray into low level programming, so learning Rust first was great because I internalized their ownership rules. However, I started to realize that Rust was doing quite a bit of stuff behind my back, like freeing objects when dropped, or making allocations when I inserted an item. This is a big no-no for realtime programming, and Rust didn't help me understand what was happening. It was then that I read matklad's blog post on rust hard mode, https://matklad.github.io/2022/10/06/hard-mode-rust.html. I looked at some of his other blog posts too, and saw Zig. So Zig had been in the back of my mind for a while, when I decided to port a Tcl interpreter to Zig. I've been about 7 months in now making my own interpreter, and it's been a delightful language. Yes, I've had my share of memory leaks and double frees, but the debugging trace lets me capture a stack track at each reference count increment and decrement, so I'm able to hunt them down pretty well. I'm also hyper aware of memory layout and allocation failure, because allocation is fallible in Zig. The error union handling makes it pretty easy to propagate OOM though, so it's not hard to make code that's resilient to OOM. If I had tried to make this in Rust, I would have been fighting the standard library, ecosystem, and borrow checker constantly, because high level programming languages have non-trivial ownership semantics, and a lot of optimizations like epoch based variable caching just don't play nicely with references as trees.

onlyrealcuzzo2• 2 months ago

We’ll be releasing 0.17.0 within a couple weeks from now.

This is amazing. Didn't 0.16 take >1 year?

I was not expecting such a fast 0.17 release, but am very pleased to find this out today.

peesem• 2 months ago

mainly because this build system change, along with upgrading to LLVM 22, are the only major changes for 0.17.0: https://ziglang.org/download/0.16.0/release-notes.html#Roadm...

Decabytes2• 2 months ago

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low level programming language really well, you'll most likely have to re familiarize yourself with the language before doing the low level stuff.

This makes Cpp and Rust harder to use then say C, so C becomes the default for me. But C is not without its issues of which we are aware. But Zig feels like it could fill that sweet spot really well, being simple enough that it's easier to pick up after a long break, but still coming with a lot of modern tooling that makes programming easier.

dnautics3• 2 months ago

this was the general motivation for my project zigler:

https://github.com/E-xyza/zigler

Decabytes2• 2 months ago

Very cool use of Elixir! I have been considering the Fig Stack (F# + Zig) myself, so I'm excited to see Zig being paired with a Functional Language

tl• 2 months ago

The OG of these is probably C and Assembly. C and (Emacs) Lisp is well known. Arguably, it's the entire reason we have Python. But if you want to pair Zig against something, I would look at Lua.

kristoff_it5• 2 months ago

You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed.

I think that's a neat idea, but in the reverse: do as much as you can in the lower level language, and only go up to the high level language when the convenience is worth the cost.

Roc allows this: every program has a platform written in a low-level language, and then the Roc program uses the API that the platform exposes.

https://www.roc-lang.org/

Then how you want to balance high vs low is of course up to you :^)

sunsetSamurai2• 2 months ago

roc lang looks very interesting, I see they use a lot of Zig and Rust, very unusual combo I think.

childintime• 2 months ago

C# is close to achieving that goal.

SvenL• 2 months ago

People always laugh when I mention C# in this regard. It has so many things, like pointer, you can define that memory alignment works like in C, SIMD, AoT compilation, Span<T>. I think you can do pretty much C like programming in C#.

addaon• 2 months ago

Objective-C and C?

BariumBlue• 2 months ago

A common combo for this is (was?) C and Lua. Lua is intended to be a embedded language, so good for Interop, but also also high level and easy to use.

There's a reason why Factorio uses Lua as it's scripting level language

frail_figure• 2 months ago

Neovim comes to mind. It uses clang as the core, and luajit as the extension layer on top.

satvikpendem• 2 months ago

Or just use one language that does both high level and low level programming well, such as Rust. I use it for everything now as I haven't found anything it can't do yet, especially with its OCaml like type system.

wodenokoto• 2 months ago

I believe that is how SpaCy is developed. Models are implemented in Cython and user facing API in Python.

forrestthewoods2• 2 months ago

My kingdom for Zig to have an official mechanism to emit the Linux library stubs.

Zig’s ability to crosscompile and target arbitrary versions of glibc is PURE MAGIC. I leverage this magic in an unrelated C++ build system. But I have to hack around to get those library stubs from Zig. Would love it to be an official output.

dzbarsky• 2 months ago

Check out https://github.com/cerisier/glibc-stubs-generator

forrestthewoods2• 2 months ago

Interesting. So here's my pretty hacky take on it.

https://github.com/forrestthewoods/anubis/blob/983d8a1b9ea5e...

It invokes zig on a dummy C or CPP file. Then it scrapes the output looking for specific files.

C: crt1.o, libm.so, libpthread.so, libc.so, libdl.so, librt.so, libld.so, libutil.so, libresolv.so, libc_nonshared.a, libcompiler_rt.a

C++: crt1.o, libc++abi.a, libc++.a, libunwind.a, libm.so, libpthread.so, libc.so, libdl.so, librt.so, libld.so, libutil.so, libresolv.so, libc_nonshared.a, libcompiler_rt.a

Zig is also a god send in that it has all the generated glibc header bullshit for Linux.

I've got a system that is able to cross-compile ffmpeg for Linux from Windows. Which is a shockingly painful and rare capability. Linux userspace design is so so so so so bad. So embarrassingly bad.

Andrew Kelley is a damn saint for the mountains he moved for Zig. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Now I just wish some of this capability was exposed in a slightly more formal capacity so that it could be leveraged by the broader community :)

mangomanai2• 2 months ago

fantastic

mangomanai2• 2 months ago

moat

kushagra1211• 2 months ago

One thing I appreciate about Zig's development is that a surprising amount of effort goes into tooling and developer feedback loops rather than adding language features.

A new language can survive missing a feature for a while. It's much harder to survive if every compile, link, and dependency update feels slow. The focus on making the development cycle measured in milliseconds instead of seconds seems like a good long-term bet.

dgan• 2 months ago

I wanted to try zig, but the language still moves way, way too fast, they break API for every release, so i simply couldbt keep up, while learning the language/debugging the build system/trying to actually implement what i wanted

After watching the Jetbrains interview, I still want to try again but maybe i ll wait till the 1.0 is out

Scicomath• 2 months ago

You can still use the old version if you don't have the time to update your code.

Zig: Build System Reworked

Related Stories