[saghm]

> It seems like "can switch on unsafe whenever" vs "has no escape hatches" is an obvious line in the sand and a very useful distinction with real world implications.

Sure, although to me, the obvious distinction is that one of them gives you more flexibility (since neither Go nor Fil-C is at risk for someone accidentally writing unsafe code).

> Why in the future? It exists and can be used right now. In fact, much of its appeal is being able to use existing code without needing to port to a new language; pragmatism seems like an argument in its favor.

Because "can be used" is not a statement of present use, but potential future use. You seem to be missing my entire point about theory versus practice; plenty of things might be useful in theory but don't ever get widely used in practice (e.g. because they're not user friendly enough, or they require constraints that aren't acceptable to most users). I'm not making a claim about whether Fil-C has these issues, but making a claim that as yet, there does not seem to be widespread usage of it. If it's really so seamless to drop-in as a replacement for C that's strictly safer without downsides that make it unappealing to most people, I'd expect that to change. If that doesn't happen, I'd consider that evidence that it's not actually providing meaningful safety in the real world (in the https://xkcd.com/1312/ sense)

[ssokolow]

Bearing in mind that "there should be no room for a language above assembly and below Rust" (i.e. something like what C or C++ is to Python, Java, C#, etc.) was an intentional design decision for Rust which resulted in `unsafe`.

[saghm]

It seems very common for people to misunderstand that having strict accounting for unsafe is part of why Rust does what it does so well rather than just disallowing unsafe outright. I think it's easily confused because being able to choose "how much unsafe do I want to allow, and where do I want to allow it" allows the choice "I don't want any in my own code" to be easily enforced, and that's by far the most common amount needed, but it's certainly not the only useful one. Being able to handle the edge cases without having to give up the checks entirely is a huge improvement over most alternatives.

[pjmlp]

Actually there is, given that the reference compiler depends on C++.

[ssokolow]

That's not a property of the language, it's just an optimization they made in line with the "Release a minimum viable product, then improve it" strategy they inherited from Mozilla.

Just look at how long it took LLVM to catch up to GCC. Writing a competitive optimizer pipeline is hard work.

"No room for a language above assembly and below Rust" is a design goal for what it's reasonable to build with it.

If anything, using LLVM for the default backend is completely on-brand with how much priority Rust puts on being suitable for partially or incrementally rewriting C codebases.

(Sorry for the slow reply. The tab got buried.)