Can someone who is knowledgeable in both Zig and Rust speak to which would be “better” (not even sure how to define that for this case) to learn for someone who knows Bash, Python and Go, but isn’t a software developer by trade? I’m an infrastructure engineer, but I do enjoy writing software (mostly developer tooling) and I’m looking for a new language to dip my toes into.
I second this and will also add that Zig’s use of “explicit” memory allocation (i.e. requiring an Allocator object anytime you want to allocate memory) will train you to think about memory allocation patterns in ways no other language will. Not everyone wants to think about this of course (there’s a reason most languages hide this from the user), but it’s a useful skill for writing high performance software.
I think the “both” answer is kinda right, which annoys me a little, because it is a lot to learn. But I can accept that we’ll have more and more languages in the future – more heterogeneity, with little convergence, because computing itself is getting bigger and diverse
e.g. I also think Mojo adds significant new things – not just the domain of ML, but also the different hardware devices, and some different philosophies around borrow checking, and close integration with Python
And that means there will be combinatorial amounts of glue. Some of it will be shell, some will be extern "C" kind of stuff … Hopefully not combinatorial numbers of build systems and package managers, but probably :-)
Whichever the case, you need to learn to appraise software yourself, otherwise you will have to depend on marketing pitches forever.
Try both, I usually recommend to give Rust a week and Zig a weekend (or any length of time you deem appropriate with a similar ratio), and make up your own mind.
If you’re new to low-level programming in general then Rust will almost certainly be easier for you – not easy, but easier.
Zig is a language designed by people who love the feeling of writing in C, but want better tooling and the benefit of 50 years of language design knowledge. If Rust is an attempt at “C++ done right”, Zig is maybe the closest there is right now to “C done right”. The flip side to that is part of the C idiom they cherish is being terse to the point of obscurity, and having relatively fewer places where the compiler will tell you you’re doing something wrong.
IMO the best ordering is Rust to learn the basics, C to learn the classics, and then Zig when you’ve written enough C to get physically angry at the existence of GNU Autotools.
I would also recommend “Learn Rust the Dangerous Way” once you know C (even if you already know Rust by then), to learn how to go from “C-like” code to idiomatic Rust code without losing any performance (in fact, gaining). It’s quite enlightening to see how you can literally write C code in Rust, then slowly improve it.
The quote doesn’t say that he intends it to replace C++, just that he wants to use it for problems he previously used C++ for
That is a very important distinction, because I’m very sure there are lots of C++ programmers who like programming with more abstraction and syntax than Zig will provide. They’ll prefer something closer to Rust
I’m more on the side of less abstraction for most things, i.e. “plain code”, Rust being fairly elaborate, but people’s preferences are diverse.
BTW Rob Pike and team “designed Go to replace C++” as well. They were writing C++ at Google when they started working on Go, famously because the compile times were too long for him.
That didn’t end up happening – experienced C++ programmers often don’t like Go, because it makes a lot of decisions for them, whereas C++ gives you all the knobs.
I was asked a few weeks ago, “What was the biggest surprise you encountered rolling out Go?” I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
Some people understand “replacement” to mean, “it can fill in the same niche”, while others mean, “it works with my existing legacy code”.
I always interpreted it to mean the former, so to me Zig is indeed a C++ replacement. As in, throw C++ in the garbage can, stop using it forever, and use Zig instead. Replace RAII with batch operations.
To the world: Your existing C++ code is not worth saving. Your C code might be OK.
As a university student, I’d prefer Zig more. Zig is easier to learn (it depends) and for me, I can understand some knowledge deeper when writing Zig code and using Zig libraries. Rust has higher level of abstraction which prevents you to touch some deeper concepts to some content. Zig’s principle is to let user have direct control over the code they write. Currently Zig’s documentation isn’t detailed, but the codes in std library is every straightforward, you can read it without enabling zls language server or you can use a text editor with only code highlighting feature to have a comfortable code reading expreience.
I am not an expert in Zig, but there was a thread by the person maintining the Linux kernel driver for the new apple that was written in rust about rust and zig here:
More specifically, if you’re coming from Python and Go in particular, I think you will enjoy Rust’s RAII and lifetime semantics more. Those are roughly equivalent to Python’s reference counting at compile time (or at runtime if you need to use Rc/Arc). It all ends up being a flavor of automatic memory management, which is broadly comparable to Go’s GC too. And Rust gives you the best of both worlds: 100% safe code by default (like Python, in fact, even stronger since Python lets you write “high-level, memory safe” data races without thinking but Rust makes it more explicit) and equal or higher performance than Go, with fast threading.
Zig sounds more aimed towards folks that come from C, and don’t want to jump into the “let the compiler take care of things for me” world. That said, I’m not experienced with Zig by any means, so you might want to hear from someone who is.
Regarding the original post, what if de-initialization can fail? I always found RAII to be relatively limited for reasons like that
It shouldn’t always be silent/invisible.
And I feel like if RAII actually works, then your resource problem was in some sense “easy”.
I’m not sure if RAII still works with async in Rust, but it doesn’t with C++. Once you write (manual) async code you are kind of on your own. You’re back to managing resources manually.
I googled and found some links that suggest there are some issues in that area with Rust:
And I feel like if RAII actually works, then your resource problem was in some sense “easy”.
Then why do people fuck up so much?
I’m not sure if RAII still works with async in Rust, but it doesn’t with C++. Once you write (manual) async code you are kind of on your own. You’re back to managing resources manually.
If the resource doesn’t need any asynchronous operations to be freed, works great. Which is to say, 99% of resources will still be handled by RAII.
I read through it, and as someone who has used both that whole thread is not arguing well for zig, only for rust, it has a lot of trolls in it that probably just are after lina (I know there are multiple) Most of us who prefer zig to rust are not deranged loonies like many in that conversation.
This post on why someone rewrote their Rust keyboard firmware in Zig might help you understand some of the differences between the two languages: https://kevinlynagh.com/rust-zig/
You’ll probably get along easier with Rust, but Zig might just bend your mind a little more. You need a bit more tolerance of bullshit with Zig since there’s less tooling, less existing code, and you might get stuck in ways that are new, so your progress will likely be slower. (I have one moderately popular library in Rust, but spend all my “free” time doing Zig, which I think demonstrates the difference nicely!)
I guess I think of what’s involved with learning to write Rust as more of an exercise (learn the rules of the borrow checker to effectively write programs that pass it), whereas imo with Zig there’s some real novelty in expressing things with comptime. It of course depends on your baseline; maybe sum types are new enough to you already.
One of the things I dislike about Rust’s documentation and educational material the most is that it’s structured around learning the rules of the borrow checker to write programs that pass it (effectively or not :-) ), instead of learning the rules of the borrow checker to write programs that leverage it – as you put it, effectively writing programs that pass it.
The “hands-on” approach of a lot of available materials is based on fighting the compiler until you come up with something that works, instead of showing how to build a model structured around borrow-checking from the very beginning. It really pissed me off when I was learning Rust. It’s very difficult to follow, like teaching dynamic memory allocation in C by starting with nothing but null pointers and gradually mallocing and freeing memory until the program stops segfaulting and leaking memory. And it’s really counterproductive: at the end of the day all you’ve learned is how to fix yet another weird cornercase, instead of gaining more fundamental insight into building models that don’t exhibit it.
I hope this will slowly go out of fashion as the Rust community grows beyond its die-hard fan base. I understand why a lot of material from the “current era” of Rust development is structured like this, because I saw it with Common Lisp, too. It’s hard to teach how to build borrow checker-aware models without devoting ample space to explaining its shortcomings, showing alternatives to idioms that the borrow checker just doesn’t deal well with, explaining workarounds for when there’s no way around them and so on. This is not the kind of thing I’d want to cover in a tutorial on my favourite language, either.
I don’t know Zig so I can’t weigh in on the parent question. But with the state of Rust documentation back when I learned it (2020/2021-ish) I am pretty sure there’s no way I could’ve learned how to write Rust programs without ample software development experience. Learning the syntax was pretty easy (prior exposure to functional programming helped :-) ) but learning how to structure my programs was almost completely a self-guided effort. The documentation didn’t cover it too much and asking the community for help was not the most pleasant experience, to put it lightly.
like teaching dynamic memory allocation in C by starting with nothing but null pointers and gradually mallocing and freeing memory until the program stops segfaulting and leaking memory.
That’s a good one! There is a thin line between fearless and thoughtless.
If you like Go, you might like Zig, since both are comparatively simple languages. You can keep all of either language in your head. This means lots of things are not done for you.
Rust is more like Python, both are complicated languages, that do more things for you. It’s unlikely you can keep either one fully in your head, but you can keep enough in your head to be useful.
I think this is why many people compare Rust to C++ and Zig to C. C++ is also a complicated language, I’d say it’s one of the most complicated around. Rust is not as bad as C++ yet, since it hasn’t been around long enough to have loads of cruft. Perhaps the way Rust is structured around backwards compatibility it will find a way to keep the complications reasonable. So far most Rust code-bases have enough in common that you can get along. In C++ you can find code-bases that are not similar enough that they even feel like the same language.
It should also be noted that Zig is a lot younger than Rust, so it’s not entirely clear how far down the complicated path Zig will end up, but I’d guess based on their path so far, they won’t go all in on complicated like Rust and C++.
Well, @matklad is already here, but for me coming from Go and frustrated after some time trying Rust (two times) I was motivated to try Zig by @mitchellhtalking with @kristoff why he chooses Zig for Ghostty (his terminal emulator project), and how it matches with my experience/profile…
… the reason I personally don’t like working too much in Rust, I have written rust, I think as a technology it’s a great language it has great merits but the reason I personally don’t like writing Rust is every project that I read with Rust ends up basically being chase the trade implementation around, it’s like what file is this trait defined, what file is the implementation is, how many implementations are there.. and I feel like I’m just chasing the traits and I don’t find that particularly.. I don’t know, productive I should say, I like languages that you read start on line one you read ten and that’s exactly what happened and so I think Zig’s a good fit …
At this point I felt crazy for even considering Rust. I had accomplished more in 4 days what took me 16 days in Rust. But more importantly, my abstractions were holding up.
Not speaking to the languages at all, but I’d say to choose the more mature language - Rust. Even after learning Rust, I still told people to just learn C++ if the goal was to learn that kind of language. That’s a trickier choice now (C++ vs Rust) because Rust has reached a tipping point in terms of resources, so it’s easier to recommend. Zig is just way too early and it’s still not a stable language, I wouldn’t spend the time on it unless you have a specific interest.
With all due respect, why bother with whether it is socially acceptable or not? Just do what you feel is best. I write Rust with clones/Rcs everywhere when I’m feeling lazy, and I get much more value out of Rust that way.
My code was flagged with not conforming to Rust idioms of not dealing with borrow checker and potential “performance” impact. Idiomatic I could buy it. But, from where I’m from: Python, Java, JS I think Rust with RCs still blows those PLs out of the water.
It’s not like they’re not still benefiting from it and its consequences, even if they opt out of some aspects of performance. I have a library that is full of a similar wart (RefCell), and so what? It solves lots of folks’ issues. Might there be a better way to do it? Sure. People struggle with the borrow checker in different ways, depending on their mental model coming in as well as the kinds of problems they’re solving. I feel like “horribly inefficient code” is a part of the “learn programming” loop which we come back to whenever we learn something new; you know it can be done better somehow, but you just don’t know yet, but you’ve got this kludge that lets you keep building regardless. I don’t think there’s any reason to discourage it.
Can someone who is knowledgeable in both Zig and Rust speak to which would be “better” (not even sure how to define that for this case) to learn for someone who knows Bash, Python and Go, but isn’t a software developer by trade? I’m an infrastructure engineer, but I do enjoy writing software (mostly developer tooling) and I’m looking for a new language to dip my toes into.
The real answer is both. Rust’s borrow checker is a game changer. But Zig’s
comptimeis a game changer as well.If you only have space for one, then go with Rust as the boring choice which is already at 1.0
I second this and will also add that Zig’s use of “explicit” memory allocation (i.e. requiring an Allocator object anytime you want to allocate memory) will train you to think about memory allocation patterns in ways no other language will. Not everyone wants to think about this of course (there’s a reason most languages hide this from the user), but it’s a useful skill for writing high performance software.
Reminds me of Type Checking vs. Metaprogramming; ML vs. Lisp :-) Someone should write Borrow Checking vs Metaprogramming; Rust vs. Zig
I think the “both” answer is kinda right, which annoys me a little, because it is a lot to learn. But I can accept that we’ll have more and more languages in the future – more heterogeneity, with little convergence, because computing itself is getting bigger and diverse
e.g. I also think Mojo adds significant new things – not just the domain of ML, but also the different hardware devices, and some different philosophies around borrow checking, and close integration with Python
And that means there will be combinatorial amounts of glue. Some of it will be shell, some will be
extern "C"kind of stuff … Hopefully not combinatorial numbers of build systems and package managers, but probably :-)Whichever the case, you need to learn to appraise software yourself, otherwise you will have to depend on marketing pitches forever.
Try both, I usually recommend to give Rust a week and Zig a weekend (or any length of time you deem appropriate with a similar ratio), and make up your own mind.
If you’re interested in the more philosophical perspective behind each project, check out this talk from Andrew, creator of Zig https://www.youtube.com/watch?v=YXrb-DqsBNU
I’m sure Rust must have an equivalent talk or two that knowledgeable Rust users could recommend you.
If you’re new to low-level programming in general then Rust will almost certainly be easier for you – not easy, but easier.
Zig is a language designed by people who love the feeling of writing in C, but want better tooling and the benefit of 50 years of language design knowledge. If Rust is an attempt at “C++ done right”, Zig is maybe the closest there is right now to “C done right”. The flip side to that is part of the C idiom they cherish is being terse to the point of obscurity, and having relatively fewer places where the compiler will tell you you’re doing something wrong.
IMO the best ordering is Rust to learn the basics, C to learn the classics, and then Zig when you’ve written enough C to get physically angry at the existence of GNU Autotools.
I would also recommend “Learn Rust the Dangerous Way” once you know C (even if you already know Rust by then), to learn how to go from “C-like” code to idiomatic Rust code without losing any performance (in fact, gaining). It’s quite enlightening to see how you can literally write C code in Rust, then slowly improve it.
https://cliffle.com/p/dangerust/
FWIW, the main author of zig hates this comparison, and intends zig to replace C++ more than C.
(I can’t find him saying that right now, so it’s from memory)
https://mastodon.social/@andrewrk/113229093827385106
Thank you! I scrolled his feed a bit and must have skipped over it
The quote doesn’t say that he intends it to replace C++, just that he wants to use it for problems he previously used C++ for
That is a very important distinction, because I’m very sure there are lots of C++ programmers who like programming with more abstraction and syntax than Zig will provide. They’ll prefer something closer to Rust
I’m more on the side of less abstraction for most things, i.e. “plain code”, Rust being fairly elaborate, but people’s preferences are diverse.
BTW Rob Pike and team “designed Go to replace C++” as well. They were writing C++ at Google when they started working on Go, famously because the compile times were too long for him.
That didn’t end up happening – experienced C++ programmers often don’t like Go, because it makes a lot of decisions for them, whereas C++ gives you all the knobs.
http://lambda-the-ultimate.org/node/4554
Some people understand “replacement” to mean, “it can fill in the same niche”, while others mean, “it works with my existing legacy code”.
I always interpreted it to mean the former, so to me Zig is indeed a C++ replacement. As in, throw C++ in the garbage can, stop using it forever, and use Zig instead. Replace RAII with batch operations.
To the world: Your existing C++ code is not worth saving. Your C code might be OK.
Best 5 words argument I’ve ever read against RAII.
the raison detre for the language is “Focus on debugging your application rather than debugging your programming language knowledge.”
which seems aimed squarely at c++ rather than c
As a university student, I’d prefer Zig more. Zig is easier to learn (it depends) and for me, I can understand some knowledge deeper when writing Zig code and using Zig libraries. Rust has higher level of abstraction which prevents you to touch some deeper concepts to some content. Zig’s principle is to let user have direct control over the code they write. Currently Zig’s documentation isn’t detailed, but the codes in
stdlibrary is every straightforward, you can read it without enablingzlslanguage server or you can use a text editor with only code highlighting feature to have a comfortable code reading expreience.I am not an expert in Zig, but there was a thread by the person maintining the Linux kernel driver for the new apple that was written in rust about rust and zig here:
https://mastodon.social/@lina@vt.social/113327856747090187
Read the comments as well, @lina is much more into rust than zig, so those might provide some extra perspective.
More specifically, if you’re coming from Python and Go in particular, I think you will enjoy Rust’s RAII and lifetime semantics more. Those are roughly equivalent to Python’s reference counting at compile time (or at runtime if you need to use Rc/Arc). It all ends up being a flavor of automatic memory management, which is broadly comparable to Go’s GC too. And Rust gives you the best of both worlds: 100% safe code by default (like Python, in fact, even stronger since Python lets you write “high-level, memory safe” data races without thinking but Rust makes it more explicit) and equal or higher performance than Go, with fast threading.
Zig sounds more aimed towards folks that come from C, and don’t want to jump into the “let the compiler take care of things for me” world. That said, I’m not experienced with Zig by any means, so you might want to hear from someone who is.
Regarding the original post, what if de-initialization can fail? I always found RAII to be relatively limited for reasons like that
It shouldn’t always be silent/invisible.
And I feel like if RAII actually works, then your resource problem was in some sense “easy”.
I’m not sure if RAII still works with async in Rust, but it doesn’t with C++. Once you write (manual) async code you are kind of on your own. You’re back to managing resources manually.
I googled and found some links that suggest there are some issues in that area with Rust:
https://internals.rust-lang.org/t/wanted-a-way-to-safely-manage-scoped-resources-in-async-code/14544/4
https://github.com/rust-lang/wg-async/issues/175
Then why do people fuck up so much?
If the resource doesn’t need any asynchronous operations to be freed, works great. Which is to say, 99% of resources will still be handled by RAII.
I don’t know of any evidence that there are more mistakes, compared with say
deferAlso, please tone it down a bit … some of your comments are low on information, high on emotion
I read through it, and as someone who has used both that whole thread is not arguing well for zig, only for rust, it has a lot of trolls in it that probably just are after lina (I know there are multiple) Most of us who prefer zig to rust are not deranged loonies like many in that conversation.
The Meatlotion troll admitting they were a script kiddie at the end was the pure catharsis I needed today. Thank you.
This post on why someone rewrote their Rust keyboard firmware in Zig might help you understand some of the differences between the two languages: https://kevinlynagh.com/rust-zig/
Discussed on Lobsters
You’ll probably get along easier with Rust, but Zig might just bend your mind a little more. You need a bit more tolerance of bullshit with Zig since there’s less tooling, less existing code, and you might get stuck in ways that are new, so your progress will likely be slower. (I have one moderately popular library in Rust, but spend all my “free” time doing Zig, which I think demonstrates the difference nicely!)
Oh, I had the impression as an observer that this was the reverse. Doesn’t rust bend the mind enough?
I guess I think of what’s involved with learning to write Rust as more of an exercise (learn the rules of the borrow checker to effectively write programs that pass it), whereas imo with Zig there’s some real novelty in expressing things with comptime. It of course depends on your baseline; maybe sum types are new enough to you already.
One of the things I dislike about Rust’s documentation and educational material the most is that it’s structured around learning the rules of the borrow checker to write programs that pass it (effectively or not :-) ), instead of learning the rules of the borrow checker to write programs that leverage it – as you put it, effectively writing programs that pass it.
The “hands-on” approach of a lot of available materials is based on fighting the compiler until you come up with something that works, instead of showing how to build a model structured around borrow-checking from the very beginning. It really pissed me off when I was learning Rust. It’s very difficult to follow, like teaching dynamic memory allocation in C by starting with nothing but
nullpointers and graduallymallocing andfreeing memory until the program stops segfaulting and leaking memory. And it’s really counterproductive: at the end of the day all you’ve learned is how to fix yet another weird cornercase, instead of gaining more fundamental insight into building models that don’t exhibit it.I hope this will slowly go out of fashion as the Rust community grows beyond its die-hard fan base. I understand why a lot of material from the “current era” of Rust development is structured like this, because I saw it with Common Lisp, too. It’s hard to teach how to build borrow checker-aware models without devoting ample space to explaining its shortcomings, showing alternatives to idioms that the borrow checker just doesn’t deal well with, explaining workarounds for when there’s no way around them and so on. This is not the kind of thing I’d want to cover in a tutorial on my favourite language, either.
I don’t know Zig so I can’t weigh in on the parent question. But with the state of Rust documentation back when I learned it (2020/2021-ish) I am pretty sure there’s no way I could’ve learned how to write Rust programs without ample software development experience. Learning the syntax was pretty easy (prior exposure to functional programming helped :-) ) but learning how to structure my programs was almost completely a self-guided effort. The documentation didn’t cover it too much and asking the community for help was not the most pleasant experience, to put it lightly.
That’s a good one! There is a thin line between fearless and thoughtless.
If you like Go, you might like Zig, since both are comparatively simple languages. You can keep all of either language in your head. This means lots of things are not done for you.
Rust is more like Python, both are complicated languages, that do more things for you. It’s unlikely you can keep either one fully in your head, but you can keep enough in your head to be useful.
I think this is why many people compare Rust to C++ and Zig to C. C++ is also a complicated language, I’d say it’s one of the most complicated around. Rust is not as bad as C++ yet, since it hasn’t been around long enough to have loads of cruft. Perhaps the way Rust is structured around backwards compatibility it will find a way to keep the complications reasonable. So far most Rust code-bases have enough in common that you can get along. In C++ you can find code-bases that are not similar enough that they even feel like the same language.
It should also be noted that Zig is a lot younger than Rust, so it’s not entirely clear how far down the complicated path Zig will end up, but I’d guess based on their path so far, they won’t go all in on complicated like Rust and C++.
Well, @matklad is already here, but for me coming from Go and frustrated after some time trying Rust (two times) I was motivated to try Zig by @mitchellh talking with @kristoff why he chooses Zig for Ghostty (his terminal emulator project), and how it matches with my experience/profile…
… the reason I personally don’t like working too much in Rust, I have written rust, I think as a technology it’s a great language it has great merits but the reason I personally don’t like writing Rust is every project that I read with Rust ends up basically being chase the trade implementation around, it’s like what file is this trait defined, what file is the implementation is, how many implementations are there.. and I feel like I’m just chasing the traits and I don’t find that particularly.. I don’t know, productive I should say, I like languages that you read start on line one you read ten and that’s exactly what happened and so I think Zig’s a good fit …
Basically I’m more into suckless philosophy I think, also liked @andrewrk talking about the road to 1.0 and Non-Profits vs VC-backed Startup etc… So I recommend to create something real on both using the refs posted here, some rustlings (plus bleessed.rs) and ziglings (or my online version, plus zigistry.dev) to get a better fit for you ; )
At this point I felt crazy for even considering Rust. I had accomplished more in 4 days what took me 16 days in Rust. But more importantly, my abstractions were holding up.
@andrewrk before Zig on progress so far
Not speaking to the languages at all, but I’d say to choose the more mature language - Rust. Even after learning Rust, I still told people to just learn C++ if the goal was to learn that kind of language. That’s a trickier choice now (C++ vs Rust) because Rust has reached a tipping point in terms of resources, so it’s easier to recommend. Zig is just way too early and it’s still not a stable language, I wouldn’t spend the time on it unless you have a specific interest.
If I just use Rust with RC to not dealing with borrow checker would it be socially acceptable?
With all due respect, why bother with whether it is socially acceptable or not? Just do what you feel is best. I write Rust with
clones/Rcs everywhere when I’m feeling lazy, and I get much more value out of Rust that way.My code was flagged with not conforming to Rust idioms of not dealing with borrow checker and potential “performance” impact. Idiomatic I could buy it. But, from where I’m from: Python, Java, JS I think Rust with RCs still blows those PLs out of the water.
Why even use Rust if you don’t want the borrow checker? That’s, like, the entire point of the language.
It’s not like they’re not still benefiting from it and its consequences, even if they opt out of some aspects of performance. I have a library that is full of a similar wart (
RefCell), and so what? It solves lots of folks’ issues. Might there be a better way to do it? Sure. People struggle with the borrow checker in different ways, depending on their mental model coming in as well as the kinds of problems they’re solving. I feel like “horribly inefficient code” is a part of the “learn programming” loop which we come back to whenever we learn something new; you know it can be done better somehow, but you just don’t know yet, but you’ve got this kludge that lets you keep building regardless. I don’t think there’s any reason to discourage it.Maybe they just really like the ecosystem and tooling