[jasonpeacock]

> produce memory safe software with a bit of discipline

"a bit of discipline" is doing a lot of work here.

"Just don't write (memory) bugs!" hasn't produced (memory) safe C, and they've been trying for 50yrs. The best practices have been to bolt on analyzers and strict "best practice" standards to enforce what should be part of the language.

You're either writing in Rust, or you're writing in something else + using extra tools to try and achieve the same result as Rust.

[fpoling]

As Rust Zig has type-safe enums/sum types. That alone eliminates a lot of problems with C. Plus sane error handling with good defaults that are better than Rust also contributes to code with less bugs.

Surely there is no borrow checker, but a lot of memory-safety issues with C and C++ comes from lack of good containers with sane interfaces (std::* in C++ is just bad from memory safety point of view).

If C++ gained the proper sum types, error handling and templates in Zig style 15 years ago and not the insanity that is in modern C++ Rust may not exist or be much more niche at this point.

[TuxSH]

> If C++ gained the proper sum types

AFAIK "P2688 R5 Pattern Matching: match Expression" exists and is due C++29 (what actually matters is when it's accepted and implemented by compilers anyway)

Also, cheap bound checks (in Rust) are contingent to Rust's aliasing model.

[whatevaa]

Buffer overruns are most common memory related RCE's. So bounds checking arrays/strings BY DEFAULT is needed.

[tptacek]

I actively dislike Zig's memory safety story, but this isn't a real argument until you can start showing real vulnerabilities --- not models --- that exploit the gap in rigor between the two languages. Both Zig and Rust are a step function in safety past C; it is not a given that Rust is that from Zig, or that that next step matters in practice the way the one from C does.

[dadrian]

I like Zig, although the Bun Github tracker is full of segfaults in Zig that are presumably quite exploitable. Unclear what to draw from this, though.

[1]: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

[vanderZwan]

Wasn't Bun the project where the creator once tweeted something along the lines of "if you're not willing to work 50+ hours a week don't bother applying to my team"? Because if so then I'm not surprised and also don't think Zig is really to blame for that.

[dadrian]

Not clear to me there's a correlation between hours worked and number of memory safety vulnerabilities

[blacksmith_tb]

I think the implication is something like "overwork / fraying morale from long hours means shipping more bugs".

[tptacek]

The point of memory-safe languages is to foreclose on a set of particularly nasty bugs, regardless of how frayed engineer morale is.

[fuzztester]

>I actively dislike Zig's memory safety story

Why? Interested to know.

Just for background, I have not tried out either Zig or Rust yet, although I have been interestedly reading about both of them for a while now, on HN and other places, and also in videos, and have read some of the overview and docs of both. But I have a long background in C dev earlier. And I have been checking out C-like languages for a while such as Odin, Hare, C3, etc.

[pjmlp]

Modula-2 was already a step function in safety past C, but people did not care because it wasn't given away alongside UNIX.

[rixed]

> "Just don't write (memory) bugs!" hasn't produced (memory) safe C

Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs.

Sure, it's easier to write a robust program in almost every other language. But to state that nobody ever produced a memory safe C program is just wrong. Maybe it was just rethoric for you, but I'm afraid some may read that and think it's a well established fact.

[zanellato19]

>Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs.

Can you provide examples for it? Because it honestly doesn't seem like it has ever been done.

[rixed]

I don't understand where you stand. Surely, you don't mean that all C programs have memory bugs. But on my side, I'm not claiming that discipline makes C a memory safe language either. This discussion has taken a weird turn.

[ramblerman]

> you don't mean that all C programs have memory bugs

Well all of them "potentially" do, which is enough from a security standpoint

There have been enough zero days using memory leaks that we know the percentage is also non trivial.

So yes, if programmers can write bugs they will, google SREs were the first to famously measure bugs per release as a metric instead of the old fashioned (and naive) "we aren't gonna write any more bugs"

[6P58r3MXJSLi]

postfix

sqlite

billions of installations and relatively few incidents

[zelphirkalt]

Few incidents != memory safe

Few incidents != not badly exploitable

Few incidents != no more undiscovered safety bugs/issues

I don't think your examples quite cut it.