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 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.
I can't speak for Andrew, but I didn't read this as a "diss" at all.
> 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
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.
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.
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
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
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!