Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How (memory) safe is Zig? (2021)

scattered-thoughts.net

Post reply on HN
Print view View original

71–80 of 88 posts

Re: How (memory) safe is Zig? (2021)

#71

Post by orobio »

ajross wrote: post #63
saagarjha wrote: post #47

Earlier quoted context omitted.

I don't think they said anything about that?

The point was that basically no one knows Swift, and everyone knows Java. If you want to point out a memory safe language in the "managed garbage-collected runtime" family, you probably shouldn't pick Swift.

I wouldn’t put Swift in the same ‘managed garbage-collected runtime’ family as Java, C#/.NET, Go, and Javascript, so maybe they weren’t trying to do what you think.

Swift is more like a native systems programming language that makes it easy to trade performance for ergonomics (and does so by default).

Re: How (memory) safe is Zig? (2021)

#72

Post by josephg »

throwawaymaths wrote: post #60
josephg wrote: post #59

Earlier quoted context omitted.

If everything is in arenas, lifetimes get much easier. But, the borrow checker doesn't just check lifetimes. It also checks ownership, and that variables either have a single mutable reference or immutable references. The optimizer assumes those invariants are maintained in the code. Many of its optimizations wouldn't be sound otherwise. So, if you could compile code which fails the borrow checker, there's all sorts…

Point being, there are many many individual programs where none of those things you talk about exist. So why not have a programming system where you can actually turn those things off for development velocity. I'm rejecting the idea that "opt-in" is bad. Opt-out is of course better, but "no choice" is not good.

> there are many many individual programs where none of those things you talk about exist

Which things? Programs without mutable references and aliasing concerns? Can you give an example?

Having worked in rust for a few years now, I’m not convinced you’d gain much velocity by disabling the borrow checker. Some code would be a little simpler without lifetime annotations, but you’d also end up spending a lot more time debugging your code. The borrow checker and rust type system are insanely good at finding bugs at compile time. It just takes awhile of working in rust before you stop stubbing your toe on the borrow checker’s (sometimes silly) rules.

If you want easy to write rust, you can always just lean heavily on Box and Rc, and .clone() everywhere. The trade off is your code won’t be as performant - but that doesn’t matter much if you’re prototyping.

If you care that much, rust is opensource. Fork it and turn the borrow checker off when compiling. It’s probably not even that hard to do. I’d love to hear about the experience - and what it’s like using rust without the borrow checker.

Re: How (memory) safe is Zig? (2021)

#73

Post by josephg »

throwawaymaths wrote: post #61
josephg wrote: post #58

Earlier quoted context omitted.

I don't. I think compile time static analysis is great. Upthread you said this: > there's no reason why the borrow checker must be in the compiler proper. On a technical front, I completely agree. But there's an ecosystem benefit to having the borrow checker as part of the compiler. If the borrow checker wasn't in the compiler proper, lots of people would "accidentally forget" to run it. As a result, lots of librarie…

> lots of people would "accidentally forget" to run it yeah, like how the sel4 guys accidentally forget to run their static analysis all the time. You put a badge on CI. If you "forget to run" the static analysis, then people get on you for not running it. Or people get on you if you don't have the badge. Just like how people get on people for not writing programs in rust.

Q: If we can get men on the moon, why is my lawnmower such a piece of junk?

A: The engineers who got us in to space didn’t design your lawnmower.

The SeL4 team won’t forget to run their static analysis checks. But most people aren’t at their level. Most people just want to get on with it. The borrow checker is a pain in the neck to learn - and if it were optional, you better believe lots of people would avoid it forever. I may well have been in that camp too - I found it really hard to get my head around it!

If you want a modern C-like language without rust’s borrow checker, Zig or Odin is probably a better bet. They’re both fine languages.

> Just like how people get on people for not writing programs in rust.

Who? Where?

Re: How (memory) safe is Zig? (2021)

#74

Post by josephg »

throwawaymaths wrote: post #54
alpaca128 wrote: post #44

Earlier quoted context omitted.

There's also no reason to have a separate borrow checker if it could just be integrated in the compiler. When a compiler has a borrow checker that means the language was already designed to enable borrow checking in the first place. And if a language can let you do borrow checking why would you use a separate tool?

because it gets it out of the fast path compile cycle. do you need a borrow checker for `ls`? Probably not. don't use it. do you need it every time you work through intermediate ideas in a refactor? probably not. just turn it on in CI.

> do you need a borrow checker for `ls`? Probably not.

Does ls use references and objects with lifetimes? I bet it does. And if so, the answer is yes. You do need the borrow checker in rust to make sure it uses memory and lifetimes correctly.

If your program somehow doesn’t use references or owned objects, then the borrow checker doesn’t have any work to do. So there’s no harm done in leaving it on.

Re: How (memory) safe is Zig? (2021)

#75

Post by pizlonator »

comex wrote: post #70
pizlonator wrote: post #55

Earlier quoted context omitted.

> Surely Fil-C cannot provide direct access to syscalls without violating the safety guarantee. There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer. This is exactly what Fil-C does. > all the known disadvantages of C and C++ The main disadvantage of C and C++ is unsafety and fil-C comprehensively fixes that. > edit: I feel bad writing such a dismissive comment, bu…

> This is exactly what Fil-C does. Okay, I just checked. It does not. I wrote: "There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer." And sure enough, your runtime manually wraps each Linux syscall to do exactly that: https://github.com/pizlonator/llvm-project-deluge/blob/6804d... For harder cases like fcntl, where arguments can be either pointers or integers, you…

It’s true that the Fil-C approach focuses on having a memory safe userland with no exceptions, which means no FFI to unsafe code (aside from the Fil-C runtime itself, which is just syscalls wrappers and a small handful of other things).

I have considered what FFI to native could look like, and have so far rejected it because it hurts the “no unsafe code” purism.

You’re right that this limits me to those OSes where the syscalls themselves are an adequate ABI. Linux isn’t the only such OS. It just happens to be the only OS Fil-C supports right now.

Re: How (memory) safe is Zig? (2021)

#76

Post by pizlonator »

steveklabnik wrote: post #67
pizlonator wrote: post #65

Earlier quoted context omitted.

You're equating a core runtime that doesn't grow with libraries written by anyone. There's no world in which a Fil-C user would write unsafe code. That's not a thing you can do in Fil-C. Rust users write unsafe code a lot and the language allows it and encourages it even.

> Rust users write unsafe code a lot This isn't the case.

Over 170 uses of unsafe in sudo-rs. That’s just one example.

That’s “a lot” in my book.

Re: How (memory) safe is Zig? (2021)

#77

Post by pizlonator »

Rusky wrote: post #66
pizlonator wrote: post #65

Earlier quoted context omitted.

You're equating a core runtime that doesn't grow with libraries written by anyone. There's no world in which a Fil-C user would write unsafe code. That's not a thing you can do in Fil-C. Rust users write unsafe code a lot and the language allows it and encourages it even.

I mean, again, yeah. I specifically compared the safe API/unsafe implementation aspect, not who writes the unsafe implementation. To me the interesting thing about Rust's approach is precisely this ability to compose unrelated pieces of trusted code. The type system and dynamic semantics are set up so that things don't just devolve into a yolo-C-style free-for-all when you combine two internally-unsafe APIs: if they…

It’s not about who writes it.

The important question is: is this a per-program recurring cost, or a per-language-implementation fixed cost.

That’s unsafe is a recurring cost.

Fil-C’s runtime is a fixed cost.

Re: How (memory) safe is Zig? (2021)

#78

Post by Rusky »

pizlonator wrote: post #77
Rusky wrote: post #66

Earlier quoted context omitted.

I mean, again, yeah. I specifically compared the safe API/unsafe implementation aspect, not who writes the unsafe implementation. To me the interesting thing about Rust's approach is precisely this ability to compose unrelated pieces of trusted code. The type system and dynamic semantics are set up so that things don't just devolve into a yolo-C-style free-for-all when you combine two internally-unsafe APIs: if they…

It’s not about who writes it. The important question is: is this a per-program recurring cost, or a per-language-implementation fixed cost. That’s unsafe is a recurring cost. Fil-C’s runtime is a fixed cost.

Yeah, you're still responding to something I'm not saying, and not saying anything I'm trying to argue with.

I wrote "who" as shorthand for "the language implementation vs the individual programs."

Re: How (memory) safe is Zig? (2021)

#79

Post by steveklabnik »

pizlonator wrote: post #76
steveklabnik wrote: post #67

Earlier quoted context omitted.

> Rust users write unsafe code a lot This isn't the case.

Over 170 uses of unsafe in sudo-rs. That’s just one example. That’s “a lot” in my book.

There’s no reason to believe that one program is inherently representative. sudo-rs eschews dependencies and so is likely to be higher than most programs.

Furthermore, 170 uses in a 200 line program vs a one million line program are very different. I don’t know off hand how big sudo-rs is.

Even in embedded OS kernels, it’s often around 1%-5% of code. Many programs have no direct unsafe code at all.

Re: How (memory) safe is Zig? (2021)

#80

Post by throwawaymaths »

steveklabnik wrote: post #68
throwawaymaths wrote: post #54

Earlier quoted context omitted.

because it gets it out of the fast path compile cycle. do you need a borrow checker for `ls`? Probably not. don't use it. do you need it every time you work through intermediate ideas in a refactor? probably not. just turn it on in CI.

The borrow checker is very fast.

computationally. But it slows down the programmer. It is not a zero-cost human operation. If it were, we wouldn't need computers to do it.
Post reply on HN