It seems completely unimportant. Don't waste time on this kind of useless debate. It goes nowhere.
Your notion of thread safety is already covered by memory safety.
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.
A data race can violate memory safety, thatâs why Rust bothers to prevent them. A higher-level race condition, on its own, cannot.
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.
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!
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.
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).
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.
Rust is a systems programming language that runs blazingly fast, prevents segfaults and data races.
This seems reasonable indeed.
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.
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.
Okay so for clarity here, letâs get into the nitty gritty of linguistics and English.
- Denotative vs connotative: Denotation is the literal dictionary definition. Connotation is the implied meaning as used in the sentence.
- 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).
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.
Aside: You might find this interesting:
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:
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.
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.
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.
The issue here is that your original statement said âguarantees safetyâ, without qualifiers and there is are memory safety concerns that have nothing to do with construction/destruction, such as iterator invalidation, out of bounds accesses and null pointer dereferences, all of which Rust fixes. RAII is not an attempt at general safety in any way, itâs only an attempt at automatic, deterministic resource management, whether talking about it in Rust or C++.
I completely agree! Note that I put âguaranteesâ in scare quotes, because the point of my post was that this is a common belief about C++, which I think is incorrect.
None of the issues you mentioned can happen if C++ is âused correctlyâ, which is what I said in my original post. But the whole problem is that this is essentially tautological (in any language) and therefore unhelpful.
First lemme reply to the linked objections:
Itâs clearly not fast enough if you need unsafe to get real performance - which is the reason this cve was possible.
You donât need unsafe to get real performance. There are certain structures and actions (eg calling C code) where unsafe is necessary, but this is not equivalents to performance. There are certain situations where you can use unsafe to get better performance than a safe approach, but even the safe performance would be way better than Python or even JS. Going by the computer language benchmarks game, Rust can usually do about as well as C and sometimes better. IIRC this had to be idiomatic and the one program source I looked at didnât have any use of unsafe.
Itâs clearly not preventing segfaults - which this cve shows.
Rust does prevent segfaults. But it does not prevent all segfaults. Especially if you use unsafe. This is like if you buy a cutting tool with a safety guard, and you remove the safety guard for some (even legitimate) reason. The safety guard can still prevent a huge number of injuries.
It also canât prevent deadlocks so it is not guaranteeing thread safety.
This really depends on what someone means by thread-safe. Often times I hear thread safety being used in the context of data races, which Rust does prevent.
For front and page stuff, I would couch it in verbiage which will ideally be meaningful to someone at management level who is googling Rust because someone is mentioning it. Whatâs it going to do for them? Well, if theyâre running into a lot of crashes with C++ because of memory issues (off by one, use after free), and data races in multithreaded code, Rust can fix those problems. Or if theyâre looking for a âsafeâ alternative to JavaScript or Python thatâs performant where they donât have to worry about shooting themselves in the foot without a great deal of discipline and training.
So at a high level Iâd only really maybe take exception with the thread safety comment, but itâs such a core part of the language and hard to quantify that Iâm not sure thereâs a better way to put it.
Two things I donât see captured very well in that statement are program correctness and refactoring with confidence. However these I would agree that âguaranteesâ is too strong, but I think Rust offers a confidence in software that is of real value.