Let's reword front page claims

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

[ahmedcharles]

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

[BatmanAoD]

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.

[spease]

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.

[BatmanAoD]

A separate issue is that most Rust introductory and promotional material states that Rust “pursues the trifecta: speed, safety, and concurrency”.

So, here’s a revised proposal:

Rust is a systems programming language that targets speed, safety, and concurrency. Idiomatic Rust is blazingly fast and enables parallelism without sacrificing memory safety or risking undefined behavior.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.