Hacker News new | ask | show | jobs
by dundarious 4 days ago
> claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks)

If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

1 comments

Machine code is unsafe, so any memory-safe language must necessarily be built on some unsafe code somewhere. Safety is always conditional on the underlying unsafe implementation having no bugs.

With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies.

So either way you're in the same situation of relying on the correctness of the unsafe code you depend on. But there are two major differences:

- Unsafe code can be written in Rust, instead of inside the compiler. This is much easier to write and to review for correctness.

- People other than Fil are allowed to write unsafe Rust. This is what Fil's point is about, and yes, it allows you to opt-in to increasing your attack surface by trusting unsafe code written by yourself or your dependents. Rust allows the user to choose where they draw the trust boundary, and Fil-C does not.

It's true that Fil is probably better than I am at writing unsafe code. So "Fil-C is safer than Rust" is true in that sense. But Fil-C is certainly not safer than safe Rust. And sure, you can't run all the Rust code in the world if you compile with '--deny unsafe_code'; but Fil-C can't run all the C code in the world either. Unsafe Rust is rarely needed, mostly only if you want to do pointer crimes or FFI, and Fil-C doesn't support a lot of (perfectly legal) pointer crimes and FFI either.

Machine code could be made safe actually, however most research topics regarding strong typed Assembly, or verified Assembly, failed to gain mindshare among commercial vendors.

One such example,

https://www.microsoft.com/en-us/research/publication/safe-to...

Reasonable people can disagree with you on the point that Rust is more safe because you can write unsafe code in Rust, whereas in Fil-C you write unsafe code in the compiler.

Why might I write unsafe Rust? To do something not particularly fancy. A use case covered by normal safe Fil-C. Why might I write unsafe Fil-C (compiler) code? To improve compiler or runtime performance or add new platforms, etc. Analogous to wanting to work on Rust's IR or borrow checker.

Very different use-cases.

There are no 'unsafe' blocks in Fil-C. I think you trying to conflate 'unsafe blocks' with the fact that there might be compiler errors which might break 'safety'? Which is equally true in any system including Rust.
Exactly, my point is that the compiler and runtime are the "unsafe" portions of Fil-C, and that Fil-C and (safe) Rust are equivalent in this regard.
Any safe system has unsafe parts. Quibbling about whether these parts are called "blocks" isn't useful. The term changes nothing.
Pobody's Nerfect is not the mindset that led to Rust's innovations, nor Fil-C's.

"Blocks" are relevant as they are how you express programs, algorithms, etc., that you need in order to get something done. Lots of data structures in Rust have a little unsafe somewhere. Users will typically depend on some "specialist" crate author to write them, but it exists, and is a necessary part of practical Rust programming. The pool of unsafety is open and by necessity growing.

In Fil-C, no such specialists are needed, and the pool of unsafety is closed and fixed, no matter what programs, algorithms, data structures you use.

This is not a trivial distinction I think. I think it's easy to acknowledge, especially given its (current) performance cost.

That's a lot of words to say that the problem with Rust is that people you don't like are allowed to write unsafe code.
My god, you are insufferable, that's not my opinion at all. Just because I used quotation marks in one place, a practice that can convey multiple meanings, not all of which involve disdain. It's unfortunate that Rust, a good language that has more practical use than Fil-C, a language that I use more than Fil-C, has proselytizers such as you.