This is a relatively uninteresting quibble: the guarantees of any language only apply outside their equivalent of unsafe blocks (e.g. Python is memory safe... until you use ctypes). Pretty much everything has a way to FFI down to interact with the machine; in Rust, it's just called `unsafe`.
(One way to look at `unsafe` is that it's a tightly integrated FFI to another language called "unsafe Rust", and it benefits from having zero performance or semantic overhead.)
His point is that in the world of programming languages, "true memory safety" isn't really something achievable without making it impossible for your language to interact with things like native libraries or the OS. Given this, the concept of "true memory safety" isn't a useful one. In general when you say a language is memory safe, there's an implicit caveat that there may be explicit escape hatches. No language (except perhaps web-based JS) is "memory safe" by the strict definition so it's not a useful parameter to use when talking of languages. You instead use the weaker version.
Can't tell if trolling or not. Python doesn't market itself as memory-safe because it's completely expected that scripting languages are memory-safe. The only domain where memory safety isn't taken as given is in systems programming, which is why Rust's safety guarantees are a big selling point.
You seem to be saying that because Rust is able to provide stronger guarantees, it should make weaker claims on its main page. But just because some of Rust's benefits are verifiable, unlike those of some other languages, doesn't mean the constraints on them need to be enumerated every time they're expressed. This is not "lying."
By the same token, you should be requiring that every subjective statement on the other langs' pages have the caveat "in the opinion of the $LANG developers." Obviously no one would wear that.
"thread safety" and "memory safety" are vague terms. "thread safety" is clarified there. "memory safety" has a particular meaning in that context which is true for Rust.
The guarantees Rust makes are always only outside of unsafe blocks. After all, you can call C code in unsafe blocks. :)
The page clarifies later on that the definition of thread safety in question is "threads without data races." The 16 words on the front page of the website are not the appropriate place to go into caveats and nuances.
We've tried to come up with something succinct to replace "thread safety", but it's tough.
> Only outside unsafe blocks.
This is just true of all of our guarantees. Given that the vast, vast, vast, vast majority of Rust code is safe code, I don't feel this is misleading. Do you say that Ruby doesn't prevent segfaults due to its C FFI?
1/ It says on the tin "prevents segfaults". It does not prevent segfaults in all cases, but OK, let's debate the other claim.
2/ It also says "guarantees thread safety".
What is the Wikipedia definition of thread safety? It varies, so let's take the most common "freedom from race conditions."
Steve come and say Rust can have race conditions https://news.ycombinator.com/item?id=13376485 and that it's a common misunderstanding to think it prevents race conditions. Surely it would be great if the frontpage would not promote it!
I disagree with the segfaults bit (which is what you had been focusing on so far, and which is what I've been arguing against) but yeah, "guarantees thread safety" is iffy.
The wikipedia definition is pretty vague, it relies on a concept of "safe" that isn't defined there. It's acceptable to say that "data race safety" is "thread safety", though confusing. Rust's homepage does clarify what it means in the bullet points below that statement, so I wouldn't call this a lie. It may be misleading though, and this is a common misunderstanding as steve mentioned, so I submitted a PR to fix it https://github.com/rust-lang/rust-www/pull/685
Yes I think "data race freedom" when I see "thread-safety" (I despise this one term for being so vague).
In the punchline, "prevent segfaults" is framed in negative terms. If you put "provides memory safety" it will be a bit less evocative of specific pain, but will give a warm feeling.
Yes, to second Manish, I would love to find something that is accurate, succinct, and understandable. Concrete suggestions (from you or anyone else) very welcome.
> prevents segfaults
Only outside unsafe blocks.
> guarantees thread safety.
But you just said you can have deadlocks and race condition, so... perhaps change the frontpage?