[Rusky]

The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.

[pizlonator]

> The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

It’s not the same.

The Fil-C runtime is the same runtime in every client of Fil-C. It’s a single common trusted compute base and there’s no reason for it to grow.

On the other hand Rust programmers use unsafe all over the place, not just in some core libraries.

[Rusky]

Yeah, that's what I meant by "depends on the specific programs you're writing." Confining unsafe Rust to core libraries is totally something people do.

[pizlonator]

You're equating a core runtime that doesn't grow with libraries written by anyone.

There's no world in which a Fil-C user would write unsafe code. That's not a thing you can do in Fil-C.

Rust users write unsafe code a lot and the language allows it and encourages it even.

[steveklabnik]

> Rust users write unsafe code a lot

This isn't the case.

[pizlonator]

Over 170 uses of unsafe in sudo-rs. That’s just one example.

That’s “a lot” in my book.

[steveklabnik]

There’s no reason to believe that one program is inherently representative. sudo-rs eschews dependencies and so is likely to be higher than most programs.

Furthermore, 170 uses in a 200 line program vs a one million line program are very different. I don’t know off hand how big sudo-rs is.

Even in embedded OS kernels, it’s often around 1%-5% of code. Many programs have no direct unsafe code at all.

[Rusky]

I mean, again, yeah. I specifically compared the safe API/unsafe implementation aspect, not who writes the unsafe implementation.

To me the interesting thing about Rust's approach is precisely this ability to compose unrelated pieces of trusted code. The type system and dynamic semantics are set up so that things don't just devolve into a yolo-C-style free-for-all when you combine two internally-unsafe APIs: if they are safe independently, they are automatically safe together as well.

The set of internally-unsafe APIs you choose to compose is a separate question on top of that. Maybe Rust, or its ecosystem, or its users, are too lax about this, but I'm not really trying to have that argument. Like I mentioned in my initial comment, I find this interesting even if you just apply it within a single trusted runtime.

[pizlonator]

It’s not about who writes it.

The important question is: is this a per-program recurring cost, or a per-language-implementation fixed cost.

That’s unsafe is a recurring cost.

Fil-C’s runtime is a fixed cost.

[Rusky]

Yeah, you're still responding to something I'm not saying, and not saying anything I'm trying to argue with.

I wrote "who" as shorthand for "the language implementation vs the individual programs."