[foundry27]

I’ll propose that most Rust projects that do useful work (in the potential energy sense?) depend on unsafe code, and it’s likely going to be found in the codebases of their dependencies and transitive dependencies. But I agree with almost all of what you’re saying about C and Rust; I work on a C operating system professionally, and I know those same pain points intimately. I program in Rust for fun, and it’s great to use.

At the end of the day this isn’t a technical argument I’m trying to make, it’s a philosophical one. I think that the more we normalize eroding the core benefits the language safety features provide, one enhancement proposal at a time, one escape hatch added each year for special interfaces, the less implicit trust you can have in rust projects without reviewing them and their dependencies for correctness.

I think that trust has enormous value, and I think it would suck to lose it. (reflect: what does seeing “written in rust” as a suffix make you think about a project’s qualities before you ever read the code)

[GolDDranks]

I’ll propose that ALL Rust projects that do useful work depend on unsafe code.

If one claims otherwise, I say they have no understanding of Rust. But also, if one helds that against Rust's value promise, I, again, say that they have no understanding of Rust.

[Dylan16807]

I get the impression they're only counting code outside the standard library, in which case tons of useful programs are fully safe.

[I_AM_A_SMURF]

It's definitely all of them. Even HashMap uses unsafe.

[steveklabnik]

It’s more fundamental than that: the Rust language does not encode hardware specifics into the language, and so way deep down there, you have to write down bytes to an address that Rust considers arbitrary. Unless you only want to run programs that accept no input and take no output, which is not exactly a useful subset of programs.

[jdiez17]

Of course all software ultimately runs on hardware, which has things like registers and hidden internal state which affect how that hardware accesses or writes to physical memory and all sorts of other "unsafe" things.

In a more practical sense, all software, even Python programs, ultimately call C functions that are unsafe.

It's like that saying "all abstractions are wrong, some are useful".

> what does seeing “written in rust” as a suffix make you think about a project’s qualities before you ever read the code

By itself, that tells me very little about a project. Same thing if I see a project written in Python or Go, which are nominally memory safe programming languages. I perceive a statistically significant likelihood that software written in these languages will not segfault on me, but it's no guarantee. If I see two programs with the same functionality, where one is written in Python and another one in Rust, I also have some expectation that the one written in Rust will be more performant.

But you cannot draw general conclusions from that piece of information alone.

However, as a programmer, Rust is a tool that makes it easier for me to write code that will not segfault or cause data races.

[kloop]

> reflect: what does seeing “written in rust” as a suffix make you think about a project’s qualities before you ever read the code

That the community is going to be significantly more dramatic than average