I don’t personally understand why I would choose Zig over Rust. I think it’s long past time we closed the book on unsafe languages as a profession.
> [...] So, the way I would describe it is that Rust has a kind of like vertical memory safety approach where on the top, it’s safe. And then, on the bottom, you hit the unsafe block, and it’s not safe, right? [...] Zig is more of I would say horizontal safety approach. So, there’s no unsafe blocks where it’s all contained in, but each feature of the language models safety in a different way. So, as an example, the pointer type in Zig actually can represent alignment. In Rust, if you want to mess with pointer alignment, you have to use an unsafe block and you’ve turned off safety for alignment. In Zig, you have pointer alignment in the type. So, it’s actually completely safe, and in Rust it’s not.
And of course the reason it doesn't use anything like a borrow checker:
> [...] Zig also wants to be optimal and optimal means you want to fully use the hardware that you have. So, my hardware lets me use virtual memory and it lets me use intrusive data structures. And it lets me write code in a certain way that’s the most efficient way to use all the CPU and all the memory. So, if my language doesn’t let me use all my hardware features, it’s not optimal.
I can't help but agree. We should strive to allow optimal code to work, and we should also do our best to prevent the programmer from doing unsafe things unless they are explicit about what they're doing. Are programmers sometimes going to do the wrong thing anyway? Yes, of course. The same way that someone can get frustrated and wrap their code in unsafe, they can use @ptrToInt without thinking it through.
Memory safety is already well-defined, though. It means that you can’t write code that mishandles memory in a dangerous way. In Rust, code outside of unsafe blocks is guaranteed to have this property. As far as I know, no such feature exists in Zig. So Zig is starting from a point where it can’t guarantee the safety of any nontrivial program, right?
asan/valgrind/etc. will also pick up a lot of memory bugs for C and C++.
Outside of maybe formal proofs in languages that only exist in research labs there isn't anything that is _provably safe_. This discussion and worship of languages which advertsie themselves as "memory safe" seems a bit zealous and often not useful. I do prefer rust over C++, mainly due to better defaults (immutable variables) and stripping out the object orientated paradigm which just gets abused after 25 years of "enterprise design patterns".
After a few years, rust is going to have just as much dodgy software as much established languages. You can see it now with people trying to write in rust as pythonic as possible and littering the place with .unwrap(). That's not a sign of quality/stable software, even if it is written in a 'memory safe' language.
I should note, Rust is not the only safe language. Python is safe, as are most modern languages with garbage collection. Most code can afford a garbage collector and should probably use one. My day job is real-time network + web services with Elixir/Erlang, and it works great. Rust gets brought up in contrast to Zig because it brings the benefits of those higher-level languages down to the metal.
He says Rust is on the top safe (vertical), but not at the bottom, because the bottom isn't fully proven.
He also says Zig is horizontally safe -> there is unsafe code on any layer, but also safe code. Also, it doesn't seem like there is something like "unsafe" for Zig. How can you say anything is safe then?
So Zig has one feature that makes it harder (impossible?) to write broken code than with Rust in UNSAFE code. How does this bring anything to the table besides eloquently dismiss Rusts safety guarantees? E.g. allowing to state libraries to only have safe code in them>
Afaik Rust let's you fully use the HW as well (and as much as possible within safe code).
Examples of people writing Rust code and hitting problems of expressiveness and performance:
My experience crafting an interpreter with Rust https://ceronman.com/2021/07/22/my-experience-crafting-an-in... (I'd be interested in experiences from others who have implemented a GC'd language runtime in Rust)
Also see Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun https://news.ycombinator.com/item?id=26374268
You can argue about how much the tradeoffs matter, which is heavily domain specific. But you can't argue that the tradeoffs don't exist.
> Andrew: It’s funny how it just kind of changes course as the language gets taken more and more seriously. And now, all the comments are even starting to shift to kind of like the philosophy of memory safety and whether Zig is immoral.
I'd suggest you go listen to the podcast or at least read the "Zig Is Immoral and Unsafe" section of the transcript as well as the following one.
Only for some common memory mistakes. And ony if the compiler doesn't have a bug. This sounds like a nitpic, but let's be clear that Rust is not "safe" as if it was some global quality that covered all of the language.
Yes, I’m talking about memory safety, because memory bugs cause most vulnerabilities.
I wonder if this type of debate came up when C++ was introduced amongst C developers.
I'm tired of this meme. It's not true. Any Rust code that goes low level liberally uses unsafe{} blocks. There are also debugging and test modes in Zig that will sniff out leaks for you.
This isn't an accurate statement. Liberal use of unsafe is not common or best practice in Rust. My favorite educational series that shows how little unsafe is required to work in low-level spaces is Phil Opperman's, "Writing an OS in Rust": https://os.phil-opp.com/
That being said, I don't think most people use "Rust is safe" in an particular way that's different from saying Java is safe. Rust in many ways offers similar (and stronger) safety guarantees than Java (one of the safest langauges to date). Is Java safe? We all know that bugs can be created in every language, it's really the different classes of bugs that each language offers some defense against that sets them apart from each other.
You might be interested in looking at the CVE list for Rust programs before you conclude that safety (programming as a safe space?) is the highest principle we should aspire to. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Rust
From a first principles basis: Time will probably reveal that languages that give us accurate insights into what the hardware is doing, and thus give us better control of hardware, will yield higher programmer productivity and software quality, in the long run.
With the borrow checker those two kinds of problems mostly evaporate, or at least are statically handled by a harsh compiler. There's been some great progress (mostly from the amazing Claire Dross iirc) bringing ownership concepts to SPARK and I really hope the Ada community can focus on those concepts for a serious, ambitious next revision, a bit more dense than all the sugar we've seen for now.
Ada has lots of safety features, and to be honest, in real-time embedded software, dynamic allocation/deallocation is a big no-no, and aliasing/pointers tend to be avoided whenever one can. I sure rant a lot at review when I see some new code with pointers instead of copying, if performance is not an issue.
1) We need to move to safer languages
2) Rust is the way, the truth, and the light of safe languages even though its brand new and barely tested out in production.
The first is a defensible position, the second is why people can have a reflexively negative reaction to anybody pushing Rust.
What would get you to change your mind on this? Like, Rust has been heavily tested in serious production for years at this point. 1.0 was six years ago. Where is the bar? How much usage counts? What is no longer "brand new"?
2) More software. Particularly older software, watching Rust code bases evolve over time.
3) Most topical to this thread, watching how other approaches to safer programming shake out. Its hard to have confidence in a solution to a generic problem when you can only evaluate a single solution. For example I find Zig to be a potentially much better solution since it has a far smaller surface area.
Somebody on HN said: Rust is what you get when C++ programmers try and fix memory safety, Zig is what you get when a C programmer tries to do it, and based on the Rust and Zig code I've seen this really rings true.
Rust is on a great track, but it seems way way too early to declare victory and start claiming that everybody exploring the same safe programming space is functioning as an unethical professional.
EDIT: As an aside I enjoyed your blog post on learning Ada, stream of consciousness and all. You ask what the bar is, the bar is Ada. Decades in the market, formal standard, multiple implementations. I wish somebody would dig into why we need Rust, Zig, or something else when Ada exists. Is it just because Ada syntax is unfamilar to todays programmers or is there something fundamentally unsound about Ada?
I always find that C++ vs C comparison to be amusing, given I work with a bunch of C folks who don't like C++ but love Rust... not everyone likes languages for the same reasons. There's a grain of truth in sayings like this, but it's not the whole picture.
(I am also not saying Rust is the only thing, or that Rust should "win" over Zig, whatever that means, or anything more broadly. My comment is purely about how Rust is too "new" and "untested", in a vacuum.)
Thanks for the comment about the blog post. It was a fun one to write.
The fact that the man who literally wrote the book on what is supposed to be the future of memory safe software engineering is not an expert on the past/current state of the art is deeply concerning. Rust is a large collaborative project that has explicitly avoided having a BDFL, and maybe there are others involved with deeper expertise in the existing state of the art in memory safe languages. Maybe the problem Rust is trying to solve is fundamentally new, but I'm skeptical of that.
For all the projects out there that casually look as if they are reinventing the wheel, I wish part of their communication would be to frame themselves in terms of what came before and explain why they are different or why the world has changed or why what came before got something crucial wrong.
I think there's a few ways to tease apart what you're saying here. First of all, I think that, even if we take this at face value:
> The fact that the man who literally wrote the book on what is supposed to be the future of memory safe software engineering is not an expert on the past/current state of the art is deeply concerning.
Not having tons of practical experience with one language is not the same as "not an expert on the past/current state of the art." I am a student of programming language history, I just hadn't spent a ton of time with Ada specifically. There are a lot of programming languages out there, and unless that is your sole focus, you'll miss some.
That being said, Graydon is that kind of person, and as far as I can tell, knows everything about every language. While he hasn't been involved in Rust for a while, and Rust looked very different back when he started it, that knowledge was expressly there.
> I wish part of their communication would be to frame themselves in terms of what came before and explain why they are different
I mean, we have. "memory safety without garbage collection" was our slogan for a very long time. While Ada does have many mitigations here, fundamentally, heap allocation is unchecked, and can cause double-frees or use after frees. SPARK does give you memory saftey, but does this by being an aggressive subset that, as far as I know, doesn't let you use dynamic allocation or pointers at all.
But, moreover, it is true that we do not often compare ourselves to other languages directly. This is more of a cultural issue than anything else. Programming languages are very tribal, and even well-meaning comparisons can come across as very aggressive. We don't discourage people making these kinds of comparisons themselves, but as a project, we prefer to talk about what Rust can do, rather than about what other languages can't do. These social reasons blend into technical reasons; programming language cultures that become obsessed with talking about why they're better than others often miss out on the good parts of those other languages. In the end, I think we get better cross-pollination with other languages by not explicitly comparing and contrasting with them in our public-facing marketing. Comparisons, in, say, an RFC are fantastic. These often do get made. But that's internal facing communication, not external.
My comment was in reaction to jolux's assertion that those exploring other solutions to safety are acting in an irresponsible, unprofessional, and unethical manner. I've been digging into Zig and Ada on the side for personal projects, and thus spending time on their respective reddits and forums. And dealing with the Rust zealots trolling these communities is verging on intolerable. Like you point out, "Why Reddit is like this" is a whole other issue, but there's a reason people are reflexively defensive. This issue comes up in the content of the podcast under discussion as well. So my bar in this case was the point where we should converge on some single solution, which I don't think is representative of Rust's official stance, but it is an issue with Rust's larger informal community. Or maybe it's just a problem with Reddit and HN.
The bar I suspect you are talking about is more along the lines of should people be using Rust in production, and clearly Rust has reached that point. People with far more at stake than I have are successfully using Rust in production, and that is a necessary step forward to things like a formal standard and multiple implementations.
Your point around the outward facing marketing is interesting. It's a shame and I don't think it speaks well of us as in industry that we tend to be so tribal around discussing the deficiency and comparisons of our tools, but I can see where the idea to focus on what your own project can do is more effective messaging. Its interesting how that kind of ties back to this post https://steveklabnik.com/writing/rust-is-more-than-safety in which you dig into some of the issues marketing Rust.
FWIW you now have me wondering the same question of why does Zig deserve to exist when Ada exists as well and start to see if I can put together a decent comparison to understand the spaces they all function in.
There are literally dozens of us!
Which is what a lot of c code does too. And zig might too?
Every time I asked the same question the answer was syntax.
I wonder if we should have gone the typescript way to make the language less readable, as joked about in this post: https://blog.adacore.com/a-modern-syntax-for-ada