Introduce a memory safe compilation mode inspired by Fil-C(codeberg.org)
codeberg.org
Introduce a memory safe compilation mode inspired by Fil-C
https://codeberg.org/ziglang/zig/issues/36237
14 comments
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?
“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.
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.
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
> 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.
> 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.
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!
> 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.
Not when one isn't against the use of managed languages in systems programming, like Swift, D, C# (AOT), Nim, OCaml or oldies that lost the language wars from the 90's, like Modula-3, Oberon, Component Pascal,...
Lots of people are against that, though. Clearly. I agree that it's silly sometimes (I dearly wish OCaml or something like it was mainstream), but the implicit definition of the category that rust, zig, etc are competing in is non-managed languages.
The only point is that it's not weird for Zig to compare itself to Rust.
The only point is that it's not weird for Zig to compare itself to Rust.
Right, however Zig is late to the party, its approach to safety is like using Modula-2 or Object Pascal.
Also, not only it is hard to see which big corp would make using Zig unavoidable, AI driven programming makes most languages irrelevant, it is a matter to ask what flavour should be output be.
Which is like, why are we even arguing for manual memory management, when is the LLM doing the work.
Also, not only it is hard to see which big corp would make using Zig unavoidable, AI driven programming makes most languages irrelevant, it is a matter to ask what flavour should be output be.
Which is like, why are we even arguing for manual memory management, when is the LLM doing the work.
I think it has a lot more to do with the Bun situation.
I keep repeating the Modula-2/Object Pascal with curly brackets example.
Zig would be a good fit in the 1990's, it is out of place in the 21st century, when we know better and better type systems became more widespread in mainstream computing.
Lets not forget, Cyclone, the inspiration for Rust's typesystem, was created by AT&T, the place where UNIX and C were born, as and I quote from their site,
> Cyclone thus tries to fill an empty niche: the safe language with C’s level of control and efficiency.
https://cyclone.thelanguage.org/wiki/Why%20Cyclone/
The UNIX and C creators, after C got standardised, kept experimenting with Alef, Limbo and finally ended up with Go.
Alef failed because according to Rob Pike,
"Problem: with C's memory model in a concurrent world, hard to know when to free items.
All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming."
http://go-lang.cat-v.org/talks/slides/emerging-languages-cam...
Then we have Zig advocating for use-after-free solutions, that for all practical purposes have existed for decades, we already had Insure++, PurifyPlus, BoundsChecker in the 1990's.
And now we get Fil-C, which in case they haven't been paying attention, uses a GC, go figure!
Zig would be a good fit in the 1990's, it is out of place in the 21st century, when we know better and better type systems became more widespread in mainstream computing.
Lets not forget, Cyclone, the inspiration for Rust's typesystem, was created by AT&T, the place where UNIX and C were born, as and I quote from their site,
> Cyclone thus tries to fill an empty niche: the safe language with C’s level of control and efficiency.
https://cyclone.thelanguage.org/wiki/Why%20Cyclone/
The UNIX and C creators, after C got standardised, kept experimenting with Alef, Limbo and finally ended up with Go.
Alef failed because according to Rob Pike,
"Problem: with C's memory model in a concurrent world, hard to know when to free items.
All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming."
http://go-lang.cat-v.org/talks/slides/emerging-languages-cam...
Then we have Zig advocating for use-after-free solutions, that for all practical purposes have existed for decades, we already had Insure++, PurifyPlus, BoundsChecker in the 1990's.
And now we get Fil-C, which in case they haven't been paying attention, uses a GC, go figure!
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.
One of the banned individuals was indeed not serious: https://xcancel.com/Malix_Labs/status/2079172393105227839
I am guilty in the Rust community of being too obsessed with Zig. I don't know why. There are many other languages mentioned in a negative way but for some reason, mentioning Rust makes people very sensitive. Meanwhile, we have no problem disparaging other languages to support Rust. For those of us who have Rust and are happy with Rust, why do we need to concern ourselves with another language and their issue tracker? This happened when it was announced that TypeScript was being rewritten in Go too. I want the Rust community to be better even if it means not interacting with other programming languages. There is nothing to gain acting like bullies and thugs.
I am guilty in the Rust community of being too obsessed with Zig. I don't know why. There are many other languages mentioned in a negative way but for some reason, mentioning Rust makes people very sensitive. Meanwhile, we have no problem disparaging other languages to support Rust. For those of us who have Rust and are happy with Rust, why do we need to concern ourselves with another language and their issue tracker? This happened when it was announced that TypeScript was being rewritten in Go too. I want the Rust community to be better even if it means not interacting with other programming languages. There is nothing to gain acting like bullies and thugs.
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.
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.
> 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.
Looks like Mr. Kelly agrees with you. From the zen of zig:
- Runtime crashes are better than bugs.
- Compile errors are better than runtime crashes.
- Incremental improvements.
- Avoid local maximums.
Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.
Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though that may be too much complexity to stomach.
- Runtime crashes are better than bugs.
- Compile errors are better than runtime crashes.
- Incremental improvements.
- Avoid local maximums.
Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.
Personally, I’d like to see refinement types that allow people to elide the runtime overhead/panics. Though that may be too much complexity to stomach.
> Looks like Mr. Kelly agrees with you. From the zen of zig:
... what? No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors. Which is fine, but saying he is in agreement is nonsense.
> Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.
Many of those languages go to great lengths to avoid raw indexing: rich iterators, arenas with branded indexes, checked gets, and so on... But, sure, if you ignore all that and do `get(i).unwrap()`. Then, yes, things are exactly the "same".
I have no problem with people choosing the set of tradeoffs that works for their context. I have a problem with people acting like those tradeoffs don't exist.
... what? No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors. Which is fine, but saying he is in agreement is nonsense.
> Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.
Many of those languages go to great lengths to avoid raw indexing: rich iterators, arenas with branded indexes, checked gets, and so on... But, sure, if you ignore all that and do `get(i).unwrap()`. Then, yes, things are exactly the "same".
I have no problem with people choosing the set of tradeoffs that works for their context. I have a problem with people acting like those tradeoffs don't exist.
> No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors
>> Compile errors are better than runtime crashes
I don’t think you’re being fair here.
>> Compile errors are better than runtime crashes
I don’t think you’re being fair here.
I'm having a hard time squaring together two of the claims Andrew makes here:
- No source changes - https://codeberg.org/ziglang/zig/issues/36237#issuecomment-1...
- No escape hatches - main post
Surely there are already projects out there that rely on behaviours prohibited by Fil-C. One example that immediately comes to mind is reliance on external/C libraries.
Overall, I think adding it as a build target/ABI to the main compiler is pretty neat, but I do agree that it seems quite against the spirit of Zig (no hidden allocations, no hidden control flow). Combined with the combative title, I wonder how much of this is just "if I give them this, they will shut up about Rust."
- No source changes - https://codeberg.org/ziglang/zig/issues/36237#issuecomment-1...
- No escape hatches - main post
Surely there are already projects out there that rely on behaviours prohibited by Fil-C. One example that immediately comes to mind is reliance on external/C libraries.
Overall, I think adding it as a build target/ABI to the main compiler is pretty neat, but I do agree that it seems quite against the spirit of Zig (no hidden allocations, no hidden control flow). Combined with the combative title, I wonder how much of this is just "if I give them this, they will shut up about Rust."
More like, we might shut up about use after free not being better than what C and C++ tooling has already provided for the last 30 years.
Also, Fil-C also makes use of GC technology, which is kind of ironic.
Also, Fil-C also makes use of GC technology, which is kind of ironic.
This will be huge if accomplished.
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?
Funny I was just having a conversation about this last week... with gemini. The obvious idea being that this places zig as the main build toolchain for most software on the planet.
[deleted]
Why are they so butthurt about Rust? It’s kinda funny since most people in the Rust community don’t think about Zig at all…
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:
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
You don't need to be a Zig expert, but you do need to at least be invested in the Zig ecosystem in some way.
I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place.
If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on the future direction of the project and debating a proposed feature, I would absolutely expect people to be annoyed about the noise I'm generating.
I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place.
If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on the future direction of the project and debating a proposed feature, I would absolutely expect people to be annoyed about the noise I'm generating.
The difference is that Rust doesn't gate comments on proof-of-use, even if core contributors might find it annoying. Honestly, this is the first I've heard of such a policy in a project (though no doubt it exists elsewhere, in the infinite span of F/OSS projects).
This isn't to say Zig's stance is unreasonable, it may even be sensible. But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case. Some people may be welcome to do that; even if there is a strong technical argument or important questions being posed, you are explicitly not welcome unless you meet that criteria, as evidenced by real comments being deleted from that issue.
This isn't to say Zig's stance is unreasonable, it may even be sensible. But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case. Some people may be welcome to do that; even if there is a strong technical argument or important questions being posed, you are explicitly not welcome unless you meet that criteria, as evidenced by real comments being deleted from that issue.
> But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case.
I really didn't think that part had to be stated explicitly; I genuinely don't know why someone not invested in Zig would even feel the need to go debate on the Zig issue tracker. But even setting that aside, this is far from the first time that the core team has made it clear that we don't want the internet peanut gallery to brigade the issue tracker.
> as evidenced by real comments being deleted from that issue.
Which real comments were deleted?
I really didn't think that part had to be stated explicitly; I genuinely don't know why someone not invested in Zig would even feel the need to go debate on the Zig issue tracker. But even setting that aside, this is far from the first time that the core team has made it clear that we don't want the internet peanut gallery to brigade the issue tracker.
> as evidenced by real comments being deleted from that issue.
Which real comments were deleted?
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
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.
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:
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
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.