If rust is so inflexible that it requires the use of unsafe to solve problems, that's still rust's fault. You have to consider both safe rust behaviour as well as necessary unsafe code.
(The nuance being that sometimes there's a lot of unsafe Rust, because some domains - like kernel programming - necessitate it. But this is still a better state of affairs than having no code be correct by construction, which is the reality with C.)
But as the adjacent commenter notes: having unsafe is not inherently a problem. You need unsafe Rust to interact with C and C++, because they're not safe by construction. This is a good thing!
Ultimately every program depends on things beyond any compilers ability to verify, for example the calls to code not written in that language being correct, or even more fundamentally if you're writing some embedded program that literally has interfaces to foreign code at all the silicon (both that handles IO and that which does the computation) being correct.
The promise of rust isn't that it can make this fundamentally non-compiler-verifiable (i.e. unsafe) dependency go away, it's that you can wrap the dependency in abstractions that make it safe for users of the dependency if the dependency is written correctly.
In most domains rust don't necessitate writing new unsafe code, you rely on the existing unsafe code in your dependencies that is shared, battle tested, and reasonably scoped. This is all rust, or any programming langauge, can promise. The demand that the dependency tree has no unsafe isn't the same as the domain necessitating no unsafe, it's the impossible demand that the domain of writing the low level abstractions that every domain relies on doesn't need unsafe.
This is an argument against encapsulation. All Rust code eventually executes `unsafe` code, because all Rust code eventually interacts with hardware/OS/C-libraries. This is true of all languages. `unsafe` is part of the point of Rust.
I cannot understand why we are continuing to have to re-litigate the very simple fact that small, bounded areas of potential unsafety are less risky and difficult to audit than all lines of code being unsafe.
If Rust doesn't live up to its lofty promises, then it changes the cost-benefit analysis. You might give up almost anything to eliminate all bugs, a lot to eliminate all memory bugs, but what would you give up to eliminate some bugs?
The cost-benefit argument for Rust has always been mediated by the fact that Rust will need to interact with (or include) unsafe code in some domains. Per above, that's an explicit goal of Rust: to provide sound abstractions over unsound primitives that can be used soundly by construction.
I have heard it and I've stated it before. It's never stated in absolute confidence. As I said in another thread, if it was actually true, then Rust wouldn't need an integrated unit testing framework.
It's referring to the experience that Rust learners have, especially when writing relatively simple code, that's it tends to be hard to misuse libraries in a way that looks correct and compiles but actually fails at runtime. Rust cannot actually provide this guarantee, it's impossible in any language. However there are a lot of common simple tasks (where there's not much complex internal logic that could be subtly incorrect) where the interfaces provided by libraries they're depending on are designed to leverage the type system such that it's difficult to accidentally misuse them.
Like something like not initializing a HTTP client properly. The interfaces make it impossible to obtain an improperly initialized client instance. This is an especially distinct feeling if you're used to dynamic languages where you often have no assurances at all that you didn't typo a field name.
I can't imagine anybody seriously making that claim as a property of the language.
(edit: fixed a comma and a forgotten word)
Examples:
6 days ago: Their experience with Rust was positive for all the commonly cited reasons - if it compiles it works
8 days ago: I have to debug Rust code waaaay less than C, for two reasons: (2) Stronger type system - you get an "if it compiles it works" kind of experience
4 months ago: I've been writing Rust code for a while and generally if it compiles, it works.
5 months ago: If it’s Rust, I can just do stuff and I’ve never broken anything. Unit tests of business logic are all the QA I need. Other than that, if it compiles it works.
9 months ago: But even on a basic level Rust has that "if it compiles it works" experience which Go definitely doesn't.
Some people claim that the quote is hyperbolic because it only covers memory errors. But this bug is a memory error, so ...
GP isn't asking for examples of just anyone making that statement. They're asking for examples of Rust making that promise. Something from the docs or the like.
> Some people claim that the quote is hyperbolic because it only covers memory errors. But this bug is a memory error, so ...
It's a memory error involving unsafe code, so it would be out of scope for whatever promises Rust may or may not have made anyways.
On the other hand, what effectively random third parties say doesn't matter all that much IMO when it comes to these things because what they think a language promises has little to no bearing on what the language actually promises. If I find a bunch of randos claiming Rust promises to give me a unicorn for my birthday it seems rather nonsensical to turn around and criticize Rust for not actually giving me a unicorn in my birthday.
As the other commenter said, said promises are made by people. The problem comes from the fact that these people are not always just random internet strangers who don't know a thing about programming who say random stuff that crosses their mind. Sometimes, it comes from the authority of the Rust compiler developers themselves (who apparently also don't seem to know anything about programming, considering that they have made such retarded claims...).
Just look at any talk given by them, or any post made on any forum, or, most importantly, the many instances where such statements are made on the Rust book (which is not an official spec for the language, but it is the closest thing we have, ignoring Ferrocene's spec because rustc is not based on that...).
Also most public speakers who were extremely vocal about Rust and made cookie cutter and easy to digest content for beginner programmers were dead set on selling the language through empty promises and some weird glorification of its capabilities, bordering the behaviour of a cult. Cue in, No Boilerplate, Let's Get Rusty, etc... all of these people have said many times the "if it compiles, you know it works!" statement, which is very popular among Rust programmers, and we all know that that is not true, because anyone with any experience with Rust will be able to tell you that with unsafe Rust, you can shoot yourself in the foot.
Stop selling smoke, this is a programming language, why must it also be a cult?
I thought it was pretty clear from context that I was speaking more generally there. Suppose not.
> As the other commenter said, said promises are made by people.
Sure, but when the developers of a language collectively agree that the language they all work on should make a particular promise, I think it's reasonable to condense that to <language> promises <X> rather than writing everything out over and over.
It's kind of similar to how one might say "Company X promises Y" rather than "The management of company X promises Y". It's a convenient shorthand that I think is reasonably understood by most people.
> Rust doesn't have an official spec. How can Rust make such a promise if it does not even have an official spec or documentation where it can make it?
Rust does have official documentation [0]?
And that being said, I don't think a language needs an official spec to make a promise. As far as most programmers are concerned, I'm pretty sure the promises made in language/implementation docs are good enough. K&R was generally good enough for most C programmers before C had a spec, after all (and arguably even after to some extent) :P
> Sometimes, it comes from the authority of the Rust compiler developers themselves []. Just look at any talk given by them, or any post made on any forum
Does it? At least from what I can remember off the top of my head I don't think I've seen such claim from official Rust devs speaking in their capacity as such. Perhaps you might have links to such?
> or, most importantly, the many instances where such statements are made on the Rust book
Are there "many instances"? `rg 'compiles.*it.*works` turns up precisely one (1) instance of that statement in the Rust book [1] and slight variations on that regex don't turn up any additional instances. What the book says portrays that statement in a slightly different light than you seem to think:
> Note: A saying you might hear about languages with strict compilers, such as Haskell and Rust, is “If the code compiles, it works.” But this saying is not universally true. Our project compiles, but it does absolutely nothing! If we were building a real, complete project, this would be a good time to start writing unit tests to check that the code compiles and has the behavior we want.
I wouldn't claim that my search was comprehensive, though, and I also can't claim to know the Rust Book from cover to cover. Maybe you know some spots I missed?
> which is not an official spec for the language, but it is the closest thing we have
I believe that particular honor actually goes to the Rust Reference [2].
> Also most public speakers who were extremely vocal about Rust and made cookie cutter and easy to digest content for beginner programmers were dead set on selling the language through empty promises and some weird glorification of its capabilities, bordering the behaviour of a cult. Cue in, No Boilerplate, Let's Get Rusty, etc... all of these people have said many times the "if it compiles, you know it works!" statement, which is very popular among Rust programmers, and we all know that that is not true, because anyone with any experience with Rust will be able to tell you that with unsafe Rust, you can shoot yourself in the foot.
Again, I don't think what unrelated third parties say has any bearing on what a language actually promises. Rust doesn't owe me a unicorn on my birthday no matter how many enthusiastic public speakers I find.
[0]: https://doc.rust-lang.org/stable/
[1]: https://github.com/rust-lang/book/blob/39aeceaa3aeab845bc451...
Safe Rust code is safe. You know where unsafe code is, because it's marked as unsafe. Yes, you will need some unsafe code in an notable project, but at least you know where it is. If you don't babysit your unsafe code, you get bad things. Someone didn't do the right thing here and I'm sure there will be a post-mortem and lessons learned.
To be comparable, imagine in C you had to mark potentially UB code with ub{} to compile. Until you get that, Rust is still a clear leader.
Thankfully, it doesn't. There are very few situations which require unsafe code, though a kernel is going to run into a lot of those by virtue of what it does. But the vast majority of the time, you can write Rust programs without ever once reaching for unsafe.
Rust is written in Rust, and we still want to be able to e.g. call C code from Rust. (It used to be the case that external C code was not always marked unsafe, but this was fixed recently).