Introduce a memory safe compilation mode inspired by Fil-C

kennykartman

Zig main dev proposes to introduce a Fil-C like compilation mode to make zig safe: it's only natural to mention how that's different from Rust, right? What about all the other languages, Andrew? I'm tired to see zig head people trying to diss Rust whenever they can. It's annoying for people that enjoy both languages and it's really a hint of how toxic the zig community is.

akagusu

This will be huge if accomplished.

chlorion

Fwiw andrewk seems to be deleting comments that criticize this approach. Not a good look on his part.

espetro

As a developer without deep know-how in low-level memory mgmt., what are the most promising (or actually working) approaches to safer memory mgmt. other than Rust's borrow checker? Is Rust's credited safe approach mainly due to the borrow checker approach or rather a mix with other language features?

afdbcreid

Fil-C is an amazing, marvelous even, and useful, concept. Useful for all legacy code that will not be rewritten and/or is not performance-sensitive, that is. The only problem is that Zig has no legacy code, so Fil-C is useless there. If you can afford the performance penalty, there are much better an easier languages to choose from.

davemp

Without explicitly entering the language holy wars. I think there’s an interesting trade-off here. Static analysis based approaches restrict what is possible to express in the language (See: doubly linked lists). But can have lower dynamic overhead. Ways to work around expressiveness limitations include strategies such as using indices into an array instead of pointers. Which in turn incurs the dynamic overhead from bounds checking. Maybe zig could find a way to elide enough of the capability overhead that careful programming could get a <2x penalty vs C. Maybe explicit opt-in built in types or something. This would essentially be the reverse of unsafe blocks, but then there’s no escape hatch. Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries. This would be great for compile times and places where open source is not tenable. Regardless, I’m very happy to see another independent school of thought approach memory safety. I’ll forgive Mr. Kelly any gruffness, these topics can be quite annoying to discuss in public.

slopinthebag

It’s kinda funny how butthurt they are about Rust, especially considering that most Rust users probably don’t think about Zig at all. I’m not sure what they gain by being so antagonistic about it…

musicale

How about like clang's -fbounds-safety, which doesn't require GC?