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 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.
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!
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.
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?
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.
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.
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…
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."
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.
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.
16 comments
[ 2.7 ms ] story [ 20.4 ms ] threadI'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.
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!
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.
- 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."
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.