Hacker News Reader

Comment by kennykartman | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

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.

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!

Reply on news.ycombinator.com