I think Andrew would contend that it is memory safe, it just defines that safety in a different way than Rust:

> [...] 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.

> it just defines that safety in a different way than Rust

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?

Can rust _gaurantee_ memory safety? A lot of the core features are built on-top of unsafe {} blocks after all. Zig has it's own memory safe features which will catch a lot of memory safe bugs compared to Vanilla C.

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.

The formal proof doesn’t exist yet but the language was designed from the ground up with memory safety as a key principle.

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.

Rust proof is coming - https://www.eurekalert.org/news-releases/610682

I think the horizontal vs vertical memory safety argument needs to be better marketed. Because right now Memory safety PL is quite literally trademarked by Rust in any discussions.

I don't find the horizontal vs vertical nomenclature very helpful. The chart here spelled it out for me very clearly.

https://scattered-thoughts.net/writing/how-safe-is-zig/

In my (admittedly) very limited usage/understanding of Zig, this is a fairly accurate description of where the memory safety comes from.

now please translate it into non-marketing words, please.

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).

The safety guarantees don't come for free. There are tradeoffs. That should be clear from the fact that Rust as a language is still changing, i.e. relaxing ownership rules and adding new mechanisms to the type system. If there were no problems, then there would be no language changes necessary.

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.

This comment is a perfect example of what Andrew was talking about here:

> 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.

Well, I feel pretty strongly about this issue as someone who cares about security. It is a question of ethics to me. I mean, saying Rust is unsafe because it has the unsafe block is like saying Haskell isn’t a pure language because it has IO. Yes, but it totally misses the point. The language is designed to minimize and constrain usage of unsafe features. And, outside of unsafe blocks, you know your code is safe. This is an important guarantee.

> outside of unsafe blocks, you know your code is safe

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.

> Only for some common memory mistakes.

Yes, I’m talking about memory safety, because memory bugs cause most vulnerabilities.

Morality and ethics seem odd to apply if a programming language should be developed, which seems to be the context Andrew was mentioning. Some use cases might apply (ex. medical devices).

I wonder if this type of debate came up when C++ was introduced amongst C developers.

> Rust is "Safe"

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.

> Any Rust code that goes low level liberally uses unsafe{} blocks

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.

> 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.

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.

Why aren't you using Ada then? Serious question. Those of us that have been around a while notice all this safety rhetoric around rust and immediately think of Ada.

Ada is missing the borrowing/moving guarantees. Whenever I use dynamically allocated memory, I have to do manual memory management, with the 'unsafe' (it's called 'unchecked' deallocation for a reason) coming in then, and also even without dynamic allocation, the myriad problems coming with aliasing (pointers / 'access types'). You can handle the first one with scoped allocation ('controlled types') and the second one by 'being careful with pointers'...

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.

There's two things going on here.

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.

> even though its brand new and barely tested out in production

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"?

1) More time. Rust is what, 6ish years old now? And in those years its continued to evovle and grow.

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?

All of this is still relative, what is "more"? is it four more years? Ten more years? Twenty? How much software is "more" software?

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.

Something about your Ada post was rubbing me the wrong way, and I figured it out. I'm not trying to be negative or insulting or anything like that, and I'm not trying to make it personal since I think this observation is not limited to you but is endemic in software development, but I don't know a better way to phrase this.

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.

Still dodging my questions ;)

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.

If you want numbers, it's sadly more like Stewart's "I know it when I see it" comment. But I think we're also talking about reaching different bars.

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.

> I work with a bunch of C folks who don't like C++ but love Rust

There are literally dozens of us!

Ada has destructors and can limit pointer type to lifetimes of large memory pools, but as far as I know it doesn’t prevent use-after-free for single objects the way Rust does. Lots of Ada is embedded on small platforms where they statically allocate a fixed number of objects anyway.

"Lots of Ada is embedded on small platforms where they statically allocate a fixed number of objects anyway."

Which is what a lot of c code does too. And zig might too?

>Is it just because Ada syntax is unfamilar to todays programmers or is there something fundamentally unsound about Ada?

Every time I asked the same question the answer was syntax.

Which I think is the silliest thing in the programming world, what with all the * soup and all the undecipherable template gibberish, and the love for haskell, scala and erlang around here.

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