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.
I spend quite a bit of time in the Zig community, more as an outsider as I don’t contribute very much.
I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity?
“I'm tired to see zig head people trying to diss Rust whenever they can.”
I feel like in every Zig post you’ve got Walter Bright saying D did this 10 years ago and a bunch of other people saying Zig isn’t a robust language because it can’t do memory safety like Rust. I find it annoying, but it’s just how it is. We like to compare things we like and there will unavoidably be some negativity in there. We should try to steelman these comments. And the steelman case for Andrew’s mention of Rust here is that this is just a different approach to memory safety, and that’s it’s just more complete in the specific way he and Fil-C is referencing
I’ve seen many Zig enthusiasts who is positive to Rusts approach to memory safety (it’s definitely nice to catch things at compile time), but just don’t consider it the ultimate approach that is best for all kinds of software
> I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity?
You are right: I generalized way too much in my comment. I do not mean that all Zig communities are toxic, but at least the ones I read/participate into.
This is about a strictly-enforced form of run-time memory safety where there's no `unsafe` escape hatch that a careless programmer can misuse to undermine the memory safety mechanism. Contrasting with Rust is helpful to get that point across - which the body text of the issue does.
I can't speak for Andrew, but I didn't read this as a "diss" at all.
Sure, the point makes sense but if that's the sole point I think communication is quite bad. Fil-C is memory-safe only if the whole stack is compiled with Fil-C: this does not hold for Rust which does not require to recompile every dependency. Some dependencies cannot even be recompiled.
So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
> So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
Safe Rust still basically always links against unsafe C libraries though. Fil-C will only link against libraries compiled with Fil-C which makes for a vastly stronger guarantee.
Also, plenty of code written in Rust is not safe so "if everything was built in safe rust, then it would be as safe" does not hold. There's definitely no way to write safe inline assembly in Rust.
It would be more accurate to say Rust doesn't have the option of recompiling every dependency. If a safe Rust program links to an unsafe C module, that program is not memory safe. The "unsafe" on FFI code is not a joke.
They focus on Rust because it's the global standard everything is compared to these days. It would be good for it to have some competition, even if we also wish its critics were more careful in their phrasing.
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.
You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug.
> 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.
One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.
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.
The idea of this is that you can import libraries from C/C++ and wrap them on the filC compilation mode, I could see some fuzzing usage on this too but I do agree it's not quite where I would like to see project effort going.
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?
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…
The Zig issue tracker is for technical discussion; you are more than welcome to engage and debate the idea on its merits. But we do indeed delete meta-commentary, wild speculation, and outright hostility.
Apparently I'm not. Directly from andrewk himself:
If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say
This itself is hostility towards anyone who isn't a zig expert pretty much.
This is the Zig repository. It is totally appropriate to expect people to be Zig experts when working on Zig itself. People should understand the repository they are talking about. If you're not even invested enough to write a project in Zig, of course your opinion is nothing but noise.
For posterity here are some comments I’m curious if will be deleted
1.
> Id like a clarification on how this is safer than Rust?
(Seems reasonable enough)
2. meme image with the words “bait” and “retarded” - should be deleted
3.
> Funny how memory safety suddenly became a priority right after Bun moved to Rust.
That feels like a pretty big departure from Zig's original philosophy.
> Someone's still pretty butthurt about Jared and the Bun team.
Just toxic negativity in my opinion. Author has clearly not followed Zig closely as memory safety has always been a priority as long as it doesn’t come at the expense of Zigs other more basic goals. This isn’t serious criticism and it’s completely valid to delete it. Andrew’s interest in Fil-C predates the Bun debacle AFAICT
I did notice one comment that was there before but which is now gone. But it was a completely unserious and garbage comment (just a comment dissing Zig)
And now I see a bunch more comments that are just utterly toxic, which I also expect will be deleted.
Serious comments seem to be kept, even when they’re sceptical.
If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say
Sadly I didn't get a chance to screenshot anything, but he's definitely not just deleting the toxic comments.
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.
I spend quite a bit of time in the Zig community, more as an outsider as I don’t contribute very much.
I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity?
“I'm tired to see zig head people trying to diss Rust whenever they can.”
I feel like in every Zig post you’ve got Walter Bright saying D did this 10 years ago and a bunch of other people saying Zig isn’t a robust language because it can’t do memory safety like Rust. I find it annoying, but it’s just how it is. We like to compare things we like and there will unavoidably be some negativity in there. We should try to steelman these comments. And the steelman case for Andrew’s mention of Rust here is that this is just a different approach to memory safety, and that’s it’s just more complete in the specific way he and Fil-C is referencing
I’ve seen many Zig enthusiasts who is positive to Rusts approach to memory safety (it’s definitely nice to catch things at compile time), but just don’t consider it the ultimate approach that is best for all kinds of software
> I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity?
You are right: I generalized way too much in my comment. I do not mean that all Zig communities are toxic, but at least the ones I read/participate into.
I'm pretty sure he posts about D on every language-related post; it's not just zig.
This is about a strictly-enforced form of run-time memory safety where there's no `unsafe` escape hatch that a careless programmer can misuse to undermine the memory safety mechanism. Contrasting with Rust is helpful to get that point across - which the body text of the issue does.
I can't speak for Andrew, but I didn't read this as a "diss" at all.
By the way
> Zig will become one of the only toolchains capable of producing actually memory safe executables
there's a whole class of GC languages that can do that
I think the point here is to include C library dependencies. Which GC languages in general consider outside the scope of its memory safety.
Sure, the point makes sense but if that's the sole point I think communication is quite bad. Fil-C is memory-safe only if the whole stack is compiled with Fil-C: this does not hold for Rust which does not require to recompile every dependency. Some dependencies cannot even be recompiled.
So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
> So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
Safe Rust still basically always links against unsafe C libraries though. Fil-C will only link against libraries compiled with Fil-C which makes for a vastly stronger guarantee.
Also, plenty of code written in Rust is not safe so "if everything was built in safe rust, then it would be as safe" does not hold. There's definitely no way to write safe inline assembly in Rust.
IIUC Fil-C does not allow to freely write safe assembly language as well, right? From the inlineasm page, they say
> Parsing and analyzing the assembly. If it contains memory accesses, control flow, or anything we don't recognize, we reject it.
...But I'm no fil-c user nor expert so correct me if I'm wrong!
It would be more accurate to say Rust doesn't have the option of recompiling every dependency. If a safe Rust program links to an unsafe C module, that program is not memory safe. The "unsafe" on FFI code is not a joke.
They focus on Rust because it's the global standard everything is compared to these days. It would be good for it to have some competition, even if we also wish its critics were more careful in their phrasing.
I think it has a lot more to do with the Bun situation.
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.
You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug.
> 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.
One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.
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.
The idea of this is that you can import libraries from C/C++ and wrap them on the filC compilation mode, I could see some fuzzing usage on this too but I do agree it's not quite where I would like to see project effort going.
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?
This will be huge if accomplished.
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…
Fwiw andrewk seems to be deleting comments that criticize this approach. Not a good look on his part.
The Zig issue tracker is for technical discussion; you are more than welcome to engage and debate the idea on its merits. But we do indeed delete meta-commentary, wild speculation, and outright hostility.
Apparently I'm not. Directly from andrewk himself:
This itself is hostility towards anyone who isn't a zig expert pretty much.This is the Zig repository. It is totally appropriate to expect people to be Zig experts when working on Zig itself. People should understand the repository they are talking about. If you're not even invested enough to write a project in Zig, of course your opinion is nothing but noise.
For posterity here are some comments I’m curious if will be deleted
1.
> Id like a clarification on how this is safer than Rust?
(Seems reasonable enough)
2. meme image with the words “bait” and “retarded” - should be deleted
3.
> Funny how memory safety suddenly became a priority right after Bun moved to Rust. That feels like a pretty big departure from Zig's original philosophy.
> Someone's still pretty butthurt about Jared and the Bun team.
Just toxic negativity in my opinion. Author has clearly not followed Zig closely as memory safety has always been a priority as long as it doesn’t come at the expense of Zigs other more basic goals. This isn’t serious criticism and it’s completely valid to delete it. Andrew’s interest in Fil-C predates the Bun debacle AFAICT
I did notice one comment that was there before but which is now gone. But it was a completely unserious and garbage comment (just a comment dissing Zig)
And now I see a bunch more comments that are just utterly toxic, which I also expect will be deleted.
Serious comments seem to be kept, even when they’re sceptical.
If you see a substantive comment you think might be deleted, screenshot it. But I do see debate in there.
directly from the thread:
Sadly I didn't get a chance to screenshot anything, but he's definitely not just deleting the toxic comments.