Let's reword front page claims

[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.

[gbutler]

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

It seems completely unimportant. Don’t waste time on this kind of useless debate. It goes nowhere.

[troplin]

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”.

Your notion of thread safety is already covered by memory safety.

it’s a bug in your logic, not in the fabric of Rust

Race conditions can lead to data inconsistency. Of course its is a logic bug as is a data race. Both are part of “thread safety” IMO. I’d never market a function as “thread safe” if I know this can lead to race conditions.

Rust prevents one category of thread safety bugs, but not the others. I didn’t want to suggest that this is a bug in the language, it’s just the way it is.

[rpjohnst]

A data race can violate memory safety, that’s why Rust bothers to prevent them. A higher-level race condition, on its own, cannot.

[Centril]

I suppose you could say:

Rust is a systems programming language that runs blazingly fast, prevents segfaults and data races.

This is shorter and perhaps more accurate, but also less cool.

[gbutler]

This is shorter and perhaps more accurate, but also less cool.

I’d think if you’re going to give in to the kind of pedantry that questions the use of “guarantees thread-safety” you’d probably have to have the motto be something like:

Rust is a programming language that runs and tries to prevent segfaults, data races, and maintain thread-safety unless you use explicitly marked ‘unsafe’ code in a way that makes it not work correctly.

Yay for Motto’s! I say, screw the Pedants!

[Ixrec]

If we actually want to prevent potential misunderstandings of the slogan (which I agree are equally likely with any slogan-length phrasing), I’d much rather we make that part of the slogan link to a comprehensive technical explanation of what “guarantees thread safety” means. Do we have an existing blog post/book chapter that specifically explains this? Maybe we should write one. Maybe do that for all three slogan claims.

Personally, if I knew nothing about Rust and merely visited that page, even if I didn’t have time to read the full explanation myself, the mere presence of a link would give me more confidence that that part of the slogan has some technical meat to it and is not just marketing fluff.

[BatmanAoD]

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.

I actually disagree.

Opt-out safety, rather than opt-in, is a huge deal in the world of low level languages. C++ proponents have been saying for years that “modern” C++ features, plus the “Core Guidelines” (which, as far as I can tell, are not nearly complete), plus static analysis and dynamic sanitizer tools, will eventually provide (or even already provide) a robust solution to the problems of the language.

Indeed, these things are all genuine improvements in programming methodology and tooling—incremental improvements. But they do not fully address the problems of ubiquitous undefined behavior, and it seems unlikely that these problems can be solved given how important backwards compatibility is for C and C++.

Rust’s restriction of undefined-behavior-causing errors tounsafe blocks are not necessarily safer than the guarantees of managed languages, much less proof-based languages. But they are, I believe, a step above what can ever be achieved in C and C++ (unless the standards committees make some unprecedentedly radical changes to the core languages).

[BatmanAoD]

Your notion of thread safety is already covered by memory safety.

I think this notion of thread safety (which precludes undefined behavior without guaranteeing correct behavior) is actually a reasonable definition. Yes, Rust’s idea of “safety” specifically means memory safety, but it’s still worth making explicit the fact that this includes (a kind of) thread safety, because it is easy to think of memory safety as something that is provided by RAII or garbage collection.

I suggest this re-wording:

Rust is a systems programming language that runs blazingly fast while ensuring memory safety even for memory shared across threads. Opportunities for undefined behavior are strictly opt-in.

[sanxiyn]

Rust is a systems programming language that runs blazingly fast, prevents segfaults and data races.

This seems reasonable indeed.

[Centril]

Rust is a systems programming language that runs blazingly fast while ensuring memory safety even for memory shared across threads. Opportunities for undefined behavior are strictly opt-in.

While accurate, I think this is too technical to work as a marketing slogan. It needs to be shorter and highlight the forest instead of the trees. The current front page claims do just that in my opinion.

[BatmanAoD]

Why would a marketing slogan for a systems programming language not be technical?

I really don’t think the first sentence is too long, and the second (while important, I think) isn’t really part of the “slogan” per se.

[ZerothLaw]

Okay so for clarity here, let’s get into the nitty gritty of linguistics and English.

1. Denotative vs connotative: Denotation is the literal dictionary definition. Connotation is the implied meaning as used in the sentence.
2. Colloquial vs formal: Colloquial usage is about the generally accepted connotation behind the word or phrase. Consider the colloquial definitions of “frag” in a group of soldiers vs a group of hard drive technicians. Formal usage is itself dependent on context - formal definitions of words will vary between groups, such as technical specializations (such as the formal definition of “species” between microbiology and zoologists).

So the core question is how much colloquial and connotative definition we want to put in the motto vs formal, denotative definitions.

So if we accept the current motto’s colloquial, connotative definitions of “prevents segfaults” and “guarantees thread safety” as being specifically about memory safety and low-level data races, then it is valid and accurate.

Being pedantic really means insisting on specific denotations and formal definitions, which can vary within sub-groups of the Rust population.

Given this overall linguistic framework, I would suggest we lean towards the current motto as it is. If we do move formal/denotative, whose formal definitions do we use? And why?

I suspect that would open up an uncomfortable can of worms and unfairly privilege one group over others (who aren’t the core Rust team, which I think we can all agree should have a bit more privilege than the rest of us).

[Ixrec]

I’m happy with the current slogan wording simply because the precise technical meaning of “guarantee thread safety” is more or less “concurrent code cannot cause memory corruption without opting in to special unsafe/FFI powers”, and I’m not aware of any stronger notion of “thread safety” that any practical language has ever attempted to provide.

Obviously no language can claim to categorically prevent logic bugs in concurrent code, and pretty much every non-systems languages like Python and Javascript and whatever has some unsafe/FFI features that could trivially subvert their usual safety guarantees. What Rust, Python, Javascript, et al can all reasonably claim is that you never have to think about thread safety in those languages until you explicitly opt-in to unsafe/FFI stuff, and you never need to think about concurrent logic bugs until you explicitly write some concurrent code. That is not the case in C++ and Java, where every class you define must be written and documented with concurrency in mind (even if only to state that it’s one of the trivial cases like all fields being final/const), or else nobody can ever safely use the class in a multithreaded scenario without going back and fixing it. And even in these languages, when a class’ documentation states that it is “thread safe”, that also usually means any client code using it (that does not itself opt in to unsafe/FFI stuff) cannot cause memory corruption.

I do think there’s a legitimate, interesting question of whether the term “thread safety” is intrinsically misleading, but that’s a question for the broader programming community, not Rust specifically. Rust’s slogan seems to be using what is in my experience the typical established meaning of that phrase, and slogans are not the place to challenge a term’s established usage.

[Centril]

I’m not aware of any stronger notion of “thread safety” that any practical language has ever attempted to provide.

Aside: You might find this interesting:

Promela

Using this it is possible to verify deadlock freedom (and starvation freedom, afair).

This is however not a general purpose language but is rather used for modelling concurrent algorithms for use elsewhere.

PROMELA & SPIN is based on linear temporal logic:

Linear temporal logic

[ahmedcharles]

Whoever told you that RAII guarantees safety was the problem, because it doesn’t do that. It guarantees deterministic running of resource collection functions. There’s no way to translate that into any notion of a safety guarantee.

[BatmanAoD]

When properly used, it protects against memory leaks (not necessarily unsafe), use-after-free (very unsafe), and double-deletion (same).

I am aware that the caveat of “correct usage” essentially nullifies this as a “guarantee”. That is why I put it in scare-quotes.

[madmalik]

I don’t think that the claim would be any more correct with added caveats. Those who have the necessary context to assess these caveats are not in danger of being misled by a simplified claim. For all others it gives a wrong impression.