Let's reword front page claims

[sanxiyn]

https://www.rust-lang.org/en-US/ says:

Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

I am uncomfortable with “guarantees thread safety”. Rust does no such thing, since unsafe Rust is part of Rust. (It is Rust code that compiles and runs on stable Rust, etc.)

I am much more comfortable with “prevents segfaults”, because it does, and it is not worded “prevents all segfaults” (which is false) or “guarantees memory safety” (similarly). In general, I think all claims on Rust should consider the existence of unsafe Rust carefully.

[matklad]

I very much like “guarantees thread safety”. Like, Rust is so further ahead than Java/C#/Go in this respect, that we should literally scream about it

That said, it’s true that technically everything is a lie. Could we solve it by giving a prominent link to Rust FAQ? Perhaps we need a special entry for “what does Rust slogan mean”?

[ahmedcharles]

You seem to be pointing out that the word guarantee has the property that it is almost impossible to be used correctly and accurately, when taking in some pedantic way.

I think this instance is fine cause if you only get three words to convey Rust’s thread safety and two of those have to be thread and safety, I’m not sure what other word is better than guarantees.

Granted, if you take the definition of guarantee to be “a pledge that something will be performed in a specified manner” (mostly because the other two definitions given seem less applicable). Then I think Rust provides a useful and pragmatic pledge toward transforming code in a manner which will exhibit thread safety, given proper usage.

Honestly, given the quoted sentence, I’m surprised that there isn’t issue taken with blazingly, could be interpreted as meaning in a way that is: very fast; very slow; sexually attractive; of tremendous intensity or fervor; or exceedingly angry. Even going with very fast results in the sentence containing redundancy, i.e. very fast, fast.

[kornel]

I’m OK with that claim. For majority of users who use stdlib, Rayon, or similar, it does give pretty strong guarantee of thread safety. JavaScript is single threaded and “thread-safe”, and it doesn’t catch data races in async code.

[sanxiyn]

I think this instance is fine cause if you only get three words to convey Rust’s thread safety and two of those have to be thread and safety, I’m not sure what other word is better than guarantees.

I suggest “improves”. I am sure better words which does not lie could be found.

[Centril]

I think it is accurate to state that thread safety is guaranteed. Fundamentally, this is talking about the properties guaranteed by safe Rust’s type system which unsafe must adhere to. When using unsafe, it is the user’s responsibility to adhere to the type system invariants and Rust can’t really be blamed for this. The guarantees re. thread safety given in safe Rust have afaik been formally proven.

I’d also like to note that other languages which provide similar guarantees, or other forms of guarantees such as Haskell and Agda have a way to tell the compiler “trust me, I know what I’m doing”. For example, Haskell has unsafePerformIO :: IO a -> a which lets you cause UB if you do not preserve referential transparency at the boundary. Agda has the concept of postulates, but it is a total language otherwise…

[BatmanAoD]

When using unsafe , it is the user’s responsibility to adhere to the type system invariants and Rust can’t really be blamed for this.

I think I agree, but on the other hand, that reminds me too much of the world of C++, where RAII “guarantees” safety as long as the user does it right (a concept I think is ridiculous, because, based on the prevalence of errors even in high quality software, humans are just not capable of consistently getting these things right).

The difference, of course, is that Rust has a keyword for explicitly indicating the code blocks in which such user error is even possible (assuming the Rust implementation is correct). This is huge, but I don’t know how to express this succinctly without giving the impression that Rust’s guarantees are only an incremental improvement over those of C++ (which is already too widespread a misconception, I think).

[sanxiyn]

For example, Haskell has unsafePerformIO :: IO a -> a which lets you cause UB if you do not preserve referential transparency at the boundary.

Right. That’s why Haskell does not guarantee referential transparency. On the other hand, to address this problem Haskell has Safe Haskell language extension as part of GHC releases which recursively checks dependencies. Rust doesn’t have anything comparable.

[sanxiyn]

I don’t know how to express this succinctly without giving the impression that Rust’s guarantees are only an incremental improvement over those of C++ (which is already too widespread a misconception, I think).

My exact point is that it is an incremental improvement over C++. Although misconceptions about Rust memory safety is widespread, this is not one of them.

On the other hand, I am not sure why you think incremental improvements are “only” incremental improvements. Incremental improvements are huge. It’s how we get nice things.

[sanxiyn]

Thinking about it, maybe “guarantees thread safety” is too strong, but “improves thread safety” is too weak. What do you think of “dramatically improves thread safety”?

[Centril]

Right. That’s why Haskell does not guarantee referential transparency.

Haskell is usually referred to as a “purely functional programming language” which is really an equivalent statement to “guarantees referential transparency” in my opinion (at least the bit about it being a pure language). Even tho you may do unsafePerformIO to break referential transparency and cause UB; I would still call it a guarantee.

I think things like unsafePerformIO and unsafe { .. } can be understood as playing outside the normal rules. I don’t think it’s unfair to have a very small but helpful white lie. In the grand scheme of things, I think Rust does guarantee thread safety.

On the other hand, to address this problem Haskell has Safe Haskell language extension as part of GHC releases which recursively checks dependencies. Rust doesn’t have anything comparable.

Aside: I’ve found {-# LANGUAGE SafeHaskell #-} to be quite a useful extension; It’s for example used by the mac package due to Alejandro Russo to encode a MAC monad for information flow control purposes. I wonder if we could design something like SafeHaskell for Rust. Could be interesting, especially since we also have coherent type classes.

My exact point is that it is an incremental improvement over C++.

It might be incremental; but it is still quite the radical change in my view. It shifts the perspective completely.

What do you think of “dramatically improves thread safety”?

Feels too wordy?

[felix91gr]

I just barely started with Rust a couple months ago, but here are my two cents. This is how the topic looks from here.

The slogan feels like it’s directed to people who won’t need to fiddle with unsafe blocks for most of their Rustic career. And for that group of people, I think the slogan is accurate.

If you take the work done by the RustBelt group, you can define “thread safety” to be a very strict requirement which nonetheless Rust (and the stdlib) seem to adhere to.

Anyway. Given it’s just marketing, I’d leave the following details for the reader to find out:

1. This is only true for safe Rust.
2. The definition of “thread safety” is so and so.
3. The proof of correctness is a WIP, but so far many properties have been proven.

Otherwise, I feel like the slogan would be too big and… I prefer shorter slogans

[sanxiyn]

The slogan feels like it’s directed to people who won’t need to fiddle with unsafe blocks for most of their Rustic career. And for that group of people, I think the slogan is accurate.

I disagree. Even if you don’t write a single line of unsafe code, you may depend on unsafe code. (This is where Safe Haskell-like mechanism is necessary.) In particular, you may have FFI in your code, and FFI calls definitely (and actually, almost surely if no care is taken) can cause data race.

[troplin]

IMO the slogan is quite misleading.

“thread safe” means more than just “free of data races”. It also means no deadlocks and no general race conditions etc. Rust cannot guarantee those!

[scottmcm]

Rust does no such thing, since unsafe Rust is part of Rust

Yes, there’s a caveat for rust’s guarantees. But that’s true of every language that can call C (or write to /dev/mem, or …). And I really don’t see how “prevents segfaults” is any impacted by the existence of unsafe. (If “prevent” isn’t considered an absolute, then “guarantee” needn’t be considered one either.)

[birkenfeld]

I’d suggest asking actual users if they feel misled or betrayed by the current wording. I feel they are intelligent enough to distinguish soundbite/marketing compatible language and actual technical documentation.

If you insist on 100% truth, anything that’s short enough for the front page can be labeled untrue, given enough pedantry and/or bad faith.

[sanxiyn]

I’d suggest asking actual users if they feel misled or betrayed by the current wording. I feel they are intelligent enough to distinguish soundbite/marketing compatible language and actual technical documentation.

Good idea. I am actually raising this issue because I got called on it. Here it is: https://lobste.rs/s/bewldn#c_yyhrfm

[bujiraso]

Good idea. I am actually raising this issue because I got called on it. Here it is: https://lobste.rs/s/bewldn#c_yyhrfm

This seems important. I recommend editing it into the top post.

[gbutler]

t also means no deadlocks and no general race conditions etc.

No, Thread Safety does not mean that in my opinion. It is not unsafe to have a deadlock or race condition. It’s a bug in your program, but, it isn’t “unsafe”. It’s undesirable. It won’t lead to exploits. I may lead to DOS, but, again, it’s a bug in your logic, not in the fabric of Rust.

[gbutler]

You will waste your life arguing with someone like that.