Writing Zig has been bringing me a lot of joy. It feels like I’m working with a machine again. The memory safety guardrails are just high enough to help out without feeling like a tourist trap.
There is space to enjoy writing code with someone’s PhD dissertation, untyped dynamic free for alls, and all that in between. Zig feels like a hacker's language.
I’ve been a lurking fan of Zig for a while. Discovering they listen to IM and Bliss to code to just made me like their project even more.
Cool to see!
I'm interested in learning a lower level language a bit better. I've spent some time in Rust and C (not enough to be proficient) -- is Zig a good candidate? It seems to have a lot of interest, I'm curious about objective views on its long term progress and forecast.
I've been playing around with Zig as a potential C alternative in my stack, and I think that it's pretty good at least for toy/learning projects actually. I especially like the way `comptime` gives me superpowers.
Before Rust and Zig, I thought I disliked systems programming, while as it turned out, I mostly just disliked C.
However, when it comes to actively maintaining a serious project you do need to take extra care, since using a pre-v1 language does require a lot more efforts, since even in a post-v1 language you need to handle lib updates and such...
Also, even though I believe I'm no longer afraid of manual memory management, explicit allocators, etc. for writing regular userland applications, I still think Zig can be too low-level for certain problem domains from time to time (the same thing for C, and I believe Zig is there specifically to target C programmers), so it's really about finding out which tools would be a great fit for you in which scenarios.
Most of my work is in higher level languages and I never liked C due to its many quirks and footguns which made me think that I just didn't enjoy low level programming.
I learned that I was wrong when I spent some time hacking around lower level programming with Zig and I thoroughly enjoyed it. It just clicks for me in ways that C and C++ never did.
I was fortunate to have learnt low level programming via various BASIC, and Turbo Pascal, alongside Z80 and 8086 Assembly, that C was never special to me, other than being more cross-platform due to the way it came to be.
Luckily around the same time I also got hold of Turbo C++ 1.0, and Borland's Pascal / C++ tag team is what kept me interested.
Zig is strictly better than C. It has a better interop story than Rust. The biggest downside right now is that it isn't stable.
IMHO the main difference where you need to "think different" compared to lower level languages like C or higher level languages like C++ and Rust is memory management. The entire Zig stdlib expects allocators to be provided by the caller and there's a handful of specialized allocators in the stdlib to pick from. This opens up a lot of flexibility for explicit memory management, but to take real advantage of this new freedom requires some experimentation and unlearning when coming from most other languages.
Ok, fuck it. Today project: Porting my vector and quaternion from Rust to Zig as a learning project.
i feel like i'd want operator overloading when dealing with quaternions, which zig eschews for no good reason
Operating overloading is considered hidden control flow. I appreciate that the team set made and are adhering to principles, but it does not mitigate the downside of this omission to me. I do a lot of scientific and numerical computing, and use vectors frequently. Non-overloaded vector syntax is tough to read and write.
I'm aborting. This is an unfortunate decision.
This is what I felt initally, too. However, you easily become used to the lack of overloading, and since the language has method syntax sugar you can easily get used to .add() over +. I'd recommend you give it another shot.
>I'm aborting. This is an unfortunate decision
LOL. At least that is 20 min of trying. ( From the first message to above )
After some thought, I think I know why this is irritating. The domains I imagine Zig would be suited for are also ones where I use vector operations regularly. Almost a 1:1 overlap:
- Embedded (Accelerations, velocities, positions)
- Robotics
- Games
- Performance-critical scientific and numerical code (Cosmology, computational chemistry etc)
- 3D graphics and visualizations
Zig has builtin support for vectors[1], which I think provides some alleviation. But sure, it's not as complete or flexible as a whole vector/matrix library.
Did you try this with Julia too? Their vector & matrix support is literally first class.
Hah yea. Julia's math syntax is the best I've seen, of any language. I wish rust and python etc had something similiar! Killer feature.
Was his research incorrect? How long should he continue to try to overcome what he believes to be a show-stopper constraint?
He has other choices after all. If this represents a negative that out-weighs the positives, so be it.
These same design decisions in Zig may make it a top tier option for other tasks. Just not this one.
Zig is a joy to write; it feels like a much-improved C. Writing and cross-compiling a custom app for Windows was great. The only thing I'd mention is that there is a lot of outdated information on the net for it. Zig has evolved and changed quite a bit, leaving it quite difficult to search (or chatbot) for up-to-date information on its syntax and idioms. It can be frustrating to get so many incorrect answers.
imo, this is a liability for them, as well for those of us who are interested in zig, but don't want to break our heads and time reading zig (language impl, not zig src examples) source code just to understand the language features. I don't know if they (andy and co.) get it, or if they subscribe to "use the source, luke" mentality :)
happy to be told I am an idiot, and don't get it, but only with good reasons :)
( as a guy who did quite a lot of C earlier, including in prod, I was interested in the goals of zig, but it should work for my needs, in the sense that I describe above. )
and I will decide what is good for me :)
now, zig away!
I've been trying to understand what Zig place is in the world so I can learn more about it. I like the idea of simplicity in programming languages but, other than that and since there's Go already, what is the proposition here?
In particular:
- LLVM is not enough, let's write our own compiler.
- Interfaces are an overhead, use comptime instead or roll your own vtables.
- In a world where "memory unsafe" languages are under attack... yeah, we don't care about that.
I'm not trolling, this are serious questions from afar that I would love to figure out before investing time with Zig.
One notable thing about Zig (and Andrew) is their willingness to rethink everything, and a lack of fear of digging all the way down and building their own versions of underpinning things. They believe incremental compilation should be an option, so they have to write their own compiler, linker, etc. They're already pushing the boundaries of what new languages can do, and—eventually—will be expected to do.
[Edit: expanding]
For instance, completely platform-independent cross compilation is something Go popularized, but Zig really nailed. (In fact, if you use cgo, the generally accepted method for Go cross-compilation is to use Zig as the C compiler!)
Another interesting thing about Zig is that it happily compiles C code, but brings more modern package management. Loris Cro has described how it would be quite reasonable (and pleasant) to maintain C code using Zig: https://kristoff.it/blog/maintain-it-with-zig/
>They believe incremental compilation should be an option
May be more accurate should be they believe compiling should be insanely fast. And incremental compilation is part of the tools to achieve that.
What does incremental compilation have to do with writing your own compiler from scratch? Isn't Rust supports incremental compilation as does every language out there?
I guess he means that in order to achieve incremental compilation they need to write their own code generation and linker for every architecture and format. This is needed because incremental compilation here doesn't just mean storing object files in a cache directory (which has always worked that way). They also want to cache every analyzed function and declaration. So they have to serialize compiler state to a file. But after analysis is done, LLVM will start code generation from the beginning (which is the time expensive thing, even in debug builds)
Yes, but isn't that an implementation detail?
Shouldn't they prioritize getting to 1.0 (the language itself) and then work in implementation details like that? I mean, It's a monumental task to write compiler and linker from scratch!
Well, if your compilations turn to be submilisecond it's not an implementation detail :) *. As of now it is only supported for x86_64 Linux (only ELF format) and it has some bugs; incremental compilation is in its very early stages. Andrew talked about it in the 2024 roadmap video[1] why they are digging so low on the multiplatform toolchain (for besides incremental compilation):
- Fast build times (closely related to IC, but LLVM gives very slow development iterations, even for the compiler development)
- Language innovations: besides IC, async/await is a feature Andrew determined to not be feasable to implement with LLVM's coroutines. Async will likely not make it into 1.0, as noted in the 0.13 release notes. It is not discarted yet but neither is it the priority.
- There are architectures that don't work very well on LLVM: SPARC and RISC-V are the ones I remember
My personal point is that a language that is meant to compete with C cannot have a hard dependency on a C++ project. That, and that it's appealing to have an alternative to LLVM whenever you want to do some JIT but don't want to bring a heavy dependency
* There is also the `--watch` flag for `zig build` which re-runs every step (IC helps) everytime a file is saved.
[edit: formatting]*
Ironically all major production C compilers evolved to be written in C++.
Also if they value compilation speed that much, maybe they shouldn't be that pushy into compiling always from source, without any support for Zig binary libraries.
> Shouldn't they prioritize getting to 1.0 (the language itself)
Nope. Different languages have different priorities and different USPs. For Zig sub-second compilation / incremental compilation, cross compiling toolchain are flagship features. Without those there is no point in releasing 1.0.
They want incremental compilation at the function level. So if you change a function, you recompile just that function. This necessitates a custom linker (indeed a custom linking strategy), and (I think?) a custom compiler.
> - In a world where "memory unsafe" languages are under attack... yeah, we don't care about that.
FWIW Zig does offer spatial memory safety, but does not provide temporal memory safety in the language (e.g. "dangling references"). It also fixes most of the 'sloppyness', UB and general footguns in C and C++ (and most memory corruption issues are a side effect of those).
A fix that was already available in languages like Modula-2 and Object Pascal, but apparently needs to be packaged in curly brackets.
I think Rust is the best option for the `Need to make a project` kind of work.
It is overall better, IMHO, and the ecosystem and safety pay dividends.
But Zig has several nice things (I don't use it directly but appreciate them, and is my way to cross-compile to musl):
* Is truly faster to compile
* Is far better to cross-compile
* Is far smaller
* comptime is a much better `macro` language. I don't like the ergonomics of the split on Rust between the 2 styles of macros, where proc-macros is a cliff of complications
I think Zig fits the bill for `C is a compiler target`. Whatever I need to integrate with C or generate C I think it is now better to target Zig.
I kind of agree but my main language is actually C++ (I know, don't hate me) and, wherever C is a target I just use C++ :)
My motto since 1993, if the choice is limited between C and C++, the latter is always the answer unless the call isn't on me.
>LLVM is not enough, let's write our own compiler.
That is for speed during debug builds. For production builds zig will still rely on LLVM
Simple answer: Anywhere you'd use C, and want a nicer language. So: embedded, operating systems, drivers, compilers, PC applications etc.
I would love to try it out with a serious project, but am waiting on libs like HALs for microcontrollers, GPU API bindings, GUIs etc to mature to a usable point.
Well, I use C++ for that today and don't see much benefit in switching really. Switching to a memory-safe language is something that I can support and even sell to my team, but switching to just a "simpler" language I'm not sure...
I noticed you used scare quotes...is that because you and your team don't think simplicity is valuable?
Note that use after free story is the same as in C and C++, using a debug allocator.
The Zig stdlib and comptime features like generics and type inspection go way beyond C (and in parts also beyond C++ and Rust) though (e.g. Zig is much more than "just" a C replacement).
[deleted]
I'm excited to see how that x86 backend is, I haven't tried it yet. It's definitely an interesting step for a new language to do on its own
There are so many cool projects using Zig already. Very excited for its future!
Could you list some? (This isn't the usual snarky HN "source?" question. I suspect you know more than I do and I'm also curious about Zig!)
Just yesterday I tinkered with making my 8-bit emulators run in a terminal (specifically Ghostty and Kitty), which is totally cool IMHO ;)
Writing Zig has been bringing me a lot of joy. It feels like I’m working with a machine again. The memory safety guardrails are just high enough to help out without feeling like a tourist trap.
There is space to enjoy writing code with someone’s PhD dissertation, untyped dynamic free for alls, and all that in between. Zig feels like a hacker's language.
I’ve been a lurking fan of Zig for a while. Discovering they listen to IM and Bliss to code to just made me like their project even more.
Cool to see!
I'm interested in learning a lower level language a bit better. I've spent some time in Rust and C (not enough to be proficient) -- is Zig a good candidate? It seems to have a lot of interest, I'm curious about objective views on its long term progress and forecast.
I've been playing around with Zig as a potential C alternative in my stack, and I think that it's pretty good at least for toy/learning projects actually. I especially like the way `comptime` gives me superpowers.
Before Rust and Zig, I thought I disliked systems programming, while as it turned out, I mostly just disliked C.
However, when it comes to actively maintaining a serious project you do need to take extra care, since using a pre-v1 language does require a lot more efforts, since even in a post-v1 language you need to handle lib updates and such...
Also, even though I believe I'm no longer afraid of manual memory management, explicit allocators, etc. for writing regular userland applications, I still think Zig can be too low-level for certain problem domains from time to time (the same thing for C, and I believe Zig is there specifically to target C programmers), so it's really about finding out which tools would be a great fit for you in which scenarios.
Most of my work is in higher level languages and I never liked C due to its many quirks and footguns which made me think that I just didn't enjoy low level programming.
I learned that I was wrong when I spent some time hacking around lower level programming with Zig and I thoroughly enjoyed it. It just clicks for me in ways that C and C++ never did.
I was fortunate to have learnt low level programming via various BASIC, and Turbo Pascal, alongside Z80 and 8086 Assembly, that C was never special to me, other than being more cross-platform due to the way it came to be.
Luckily around the same time I also got hold of Turbo C++ 1.0, and Borland's Pascal / C++ tag team is what kept me interested.
Zig is strictly better than C. It has a better interop story than Rust. The biggest downside right now is that it isn't stable.
IMHO the main difference where you need to "think different" compared to lower level languages like C or higher level languages like C++ and Rust is memory management. The entire Zig stdlib expects allocators to be provided by the caller and there's a handful of specialized allocators in the stdlib to pick from. This opens up a lot of flexibility for explicit memory management, but to take real advantage of this new freedom requires some experimentation and unlearning when coming from most other languages.
Ok, fuck it. Today project: Porting my vector and quaternion from Rust to Zig as a learning project.
i feel like i'd want operator overloading when dealing with quaternions, which zig eschews for no good reason
I just hit this, within minutes of starting... A cursory search implies this is a won't-fix: https://ziglang.org/learn/overview/#small-simple-language
Operating overloading is considered hidden control flow. I appreciate that the team set made and are adhering to principles, but it does not mitigate the downside of this omission to me. I do a lot of scientific and numerical computing, and use vectors frequently. Non-overloaded vector syntax is tough to read and write.
I'm aborting. This is an unfortunate decision.
This is what I felt initally, too. However, you easily become used to the lack of overloading, and since the language has method syntax sugar you can easily get used to .add() over +. I'd recommend you give it another shot.
>I'm aborting. This is an unfortunate decision
LOL. At least that is 20 min of trying. ( From the first message to above )
After some thought, I think I know why this is irritating. The domains I imagine Zig would be suited for are also ones where I use vector operations regularly. Almost a 1:1 overlap:
Zig has builtin support for vectors[1], which I think provides some alleviation. But sure, it's not as complete or flexible as a whole vector/matrix library.
[1]: https://ziglang.org/documentation/master/#Vectors
Did you try this with Julia too? Their vector & matrix support is literally first class.
Hah yea. Julia's math syntax is the best I've seen, of any language. I wish rust and python etc had something similiar! Killer feature.
Was his research incorrect? How long should he continue to try to overcome what he believes to be a show-stopper constraint?
He has other choices after all. If this represents a negative that out-weighs the positives, so be it.
These same design decisions in Zig may make it a top tier option for other tasks. Just not this one.
Zig is a joy to write; it feels like a much-improved C. Writing and cross-compiling a custom app for Windows was great. The only thing I'd mention is that there is a lot of outdated information on the net for it. Zig has evolved and changed quite a bit, leaving it quite difficult to search (or chatbot) for up-to-date information on its syntax and idioms. It can be frustrating to get so many incorrect answers.
imo, this is a liability for them, as well for those of us who are interested in zig, but don't want to break our heads and time reading zig (language impl, not zig src examples) source code just to understand the language features. I don't know if they (andy and co.) get it, or if they subscribe to "use the source, luke" mentality :)
happy to be told I am an idiot, and don't get it, but only with good reasons :)
( as a guy who did quite a lot of C earlier, including in prod, I was interested in the goals of zig, but it should work for my needs, in the sense that I describe above. )
and I will decide what is good for me :)
now, zig away!
I've been trying to understand what Zig place is in the world so I can learn more about it. I like the idea of simplicity in programming languages but, other than that and since there's Go already, what is the proposition here?
In particular:
- LLVM is not enough, let's write our own compiler.
- Interfaces are an overhead, use comptime instead or roll your own vtables.
- In a world where "memory unsafe" languages are under attack... yeah, we don't care about that.
I'm not trolling, this are serious questions from afar that I would love to figure out before investing time with Zig.
One notable thing about Zig (and Andrew) is their willingness to rethink everything, and a lack of fear of digging all the way down and building their own versions of underpinning things. They believe incremental compilation should be an option, so they have to write their own compiler, linker, etc. They're already pushing the boundaries of what new languages can do, and—eventually—will be expected to do.
[Edit: expanding]
For instance, completely platform-independent cross compilation is something Go popularized, but Zig really nailed. (In fact, if you use cgo, the generally accepted method for Go cross-compilation is to use Zig as the C compiler!)
Another interesting thing about Zig is that it happily compiles C code, but brings more modern package management. Loris Cro has described how it would be quite reasonable (and pleasant) to maintain C code using Zig: https://kristoff.it/blog/maintain-it-with-zig/
>They believe incremental compilation should be an option
May be more accurate should be they believe compiling should be insanely fast. And incremental compilation is part of the tools to achieve that.
What does incremental compilation have to do with writing your own compiler from scratch? Isn't Rust supports incremental compilation as does every language out there?
I guess he means that in order to achieve incremental compilation they need to write their own code generation and linker for every architecture and format. This is needed because incremental compilation here doesn't just mean storing object files in a cache directory (which has always worked that way). They also want to cache every analyzed function and declaration. So they have to serialize compiler state to a file. But after analysis is done, LLVM will start code generation from the beginning (which is the time expensive thing, even in debug builds)
Yes, but isn't that an implementation detail? Shouldn't they prioritize getting to 1.0 (the language itself) and then work in implementation details like that? I mean, It's a monumental task to write compiler and linker from scratch!
Well, if your compilations turn to be submilisecond it's not an implementation detail :) *. As of now it is only supported for x86_64 Linux (only ELF format) and it has some bugs; incremental compilation is in its very early stages. Andrew talked about it in the 2024 roadmap video[1] why they are digging so low on the multiplatform toolchain (for besides incremental compilation):
- Fast build times (closely related to IC, but LLVM gives very slow development iterations, even for the compiler development)
- Language innovations: besides IC, async/await is a feature Andrew determined to not be feasable to implement with LLVM's coroutines. Async will likely not make it into 1.0, as noted in the 0.13 release notes. It is not discarted yet but neither is it the priority.
- There are architectures that don't work very well on LLVM: SPARC and RISC-V are the ones I remember
My personal point is that a language that is meant to compete with C cannot have a hard dependency on a C++ project. That, and that it's appealing to have an alternative to LLVM whenever you want to do some JIT but don't want to bring a heavy dependency
[1] https://www.youtube.com/watch?v=5eL_LcxwwHg
* There is also the `--watch` flag for `zig build` which re-runs every step (IC helps) everytime a file is saved.
[edit: formatting]*
Ironically all major production C compilers evolved to be written in C++.
Also if they value compilation speed that much, maybe they shouldn't be that pushy into compiling always from source, without any support for Zig binary libraries.
> Shouldn't they prioritize getting to 1.0 (the language itself)
Nope. Different languages have different priorities and different USPs. For Zig sub-second compilation / incremental compilation, cross compiling toolchain are flagship features. Without those there is no point in releasing 1.0.
They want incremental compilation at the function level. So if you change a function, you recompile just that function. This necessitates a custom linker (indeed a custom linking strategy), and (I think?) a custom compiler.
> - In a world where "memory unsafe" languages are under attack... yeah, we don't care about that.
FWIW Zig does offer spatial memory safety, but does not provide temporal memory safety in the language (e.g. "dangling references"). It also fixes most of the 'sloppyness', UB and general footguns in C and C++ (and most memory corruption issues are a side effect of those).
Temporal memory safety can for instance be achieved via generation-counted handles (e.g. see: https://floooh.github.io/2018/06/17/handles-vs-pointers.html and https://github.com/zig-gamedev/zpool/)
A fix that was already available in languages like Modula-2 and Object Pascal, but apparently needs to be packaged in curly brackets.
I think Rust is the best option for the `Need to make a project` kind of work.
It is overall better, IMHO, and the ecosystem and safety pay dividends.
But Zig has several nice things (I don't use it directly but appreciate them, and is my way to cross-compile to musl):
* Is truly faster to compile
* Is far better to cross-compile
* Is far smaller
* comptime is a much better `macro` language. I don't like the ergonomics of the split on Rust between the 2 styles of macros, where proc-macros is a cliff of complications
I think Zig fits the bill for `C is a compiler target`. Whatever I need to integrate with C or generate C I think it is now better to target Zig.
I kind of agree but my main language is actually C++ (I know, don't hate me) and, wherever C is a target I just use C++ :)
My motto since 1993, if the choice is limited between C and C++, the latter is always the answer unless the call isn't on me.
>LLVM is not enough, let's write our own compiler.
That is for speed during debug builds. For production builds zig will still rely on LLVM
Simple answer: Anywhere you'd use C, and want a nicer language. So: embedded, operating systems, drivers, compilers, PC applications etc.
I would love to try it out with a serious project, but am waiting on libs like HALs for microcontrollers, GPU API bindings, GUIs etc to mature to a usable point.
Well, I use C++ for that today and don't see much benefit in switching really. Switching to a memory-safe language is something that I can support and even sell to my team, but switching to just a "simpler" language I'm not sure...
I noticed you used scare quotes...is that because you and your team don't think simplicity is valuable?
Note that use after free story is the same as in C and C++, using a debug allocator.
The Zig stdlib and comptime features like generics and type inspection go way beyond C (and in parts also beyond C++ and Rust) though (e.g. Zig is much more than "just" a C replacement).
I'm excited to see how that x86 backend is, I haven't tried it yet. It's definitely an interesting step for a new language to do on its own
There are so many cool projects using Zig already. Very excited for its future!
Could you list some? (This isn't the usual snarky HN "source?" question. I suspect you know more than I do and I'm also curious about Zig!)
Just yesterday I tinkered with making my 8-bit emulators run in a terminal (specifically Ghostty and Kitty), which is totally cool IMHO ;)
https://github.com/floooh/chipz-kitty
That's one nice thing about Zig, such small experiments are quick to setup and fun to build.
TigerBeetle and Ghostty are probably the most famous.
Bun too
The C/C++ dropin compiler replacement in Zig now seems like a missed opportunity in Rust. Would that even be possible?
Rust also uses LLVM so I don't see why not. Even D has its own C compiler, does Bun too.
There are other Rust implementations that do not use LLVM. Eg. GCC and Cranelift.
Incremental compilation!
> Incremental compilation!
No entirely clear what that actually is, even from rapidly reading the github discussion
Basically a level of build artifact reuse: a code change in one place doesn't necessarily require recompiling the entire project.