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 can't speak for Andrew, but I didn't read this as a "diss" at all.
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.
> 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!
> 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 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
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.
The only point is that it's not weird for Zig to compare itself to Rust.
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!
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
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
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 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.
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.
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?
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.
> 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.
- 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.
... 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 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."
Also, Fil-C also makes use of GC technology, which is kind of ironic.
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.