TWiR quote of the week

Shared mutable state is evil, and you can solve it by forbidding mutation, or by forbidding sharing. Rust supports both.

@kornel on From 1s to 4ms | Lobsters


From lcnr on Zulip, discussing the Rust specification effort:

should the result of the following be specified, if yes, specifying method resultion relies on hir

trait Trait {
    fn abs(self) -> Self;

impl Trait for i64 {
    fn abs(self) -> Self {
        2 * self

fn main() {
    let x = 42;
    println!("{}", x.abs()); // 84
    println!("{}", x.abs()); // 42

Can somebody explain what is going on here? Somehow the first x.abs() changes the meaning of x for subsequent uses, and it's definitely something to do with the default integer pseudo type, I did some experiments here.

See this topic:


Okay. Why isn't this like an error because of ambigiuity?
Or why not take the type-method by default when one with the same name exists in an impl type and impl trait for type?

I showed this to a friend of mine and he just commented: "This is a quirk on the scale of JS or PHP."

This feels like a weird pitfall for people.

Edit: Does this happen on custom-types too - or just in build-ins?

1 Like

Please discuss this in the topic I linked above that @SebastianJL specifically created for the quote


Oldie, but goldie:

This example does not work, which is to say, it compiles.


"My experience with C++ is that, as I’ve become more of an expert in the language, I’ve become more disillusioned with it. It’s incredibly hard to do things that you should be able to do in software. And, it’s a huge problem for me to constantly be helping other engineers debug the same bugs over and over. It’s always another use after free. I’ve probably debugged 300 of those. "...

" In our experience using the Rust ecosystem for almost three years now, I don't think we found a bug in a single Rust crate that we've pulled off the shelf. We found a bug in one of them and that was a Rust crate wrapping a C library and the bug was in the C library. The software quality that you kind of get for free is amazing. "


It's important not to make the easy mistake of seeing the unsafe keyword as magic to sprinkle on code to make it faster. In fact, unsafe code can even be slower than safe code if you don't know precisely what you're doing (for example, raw pointers lose the aliasing information that mutable references carry).

From kibwen on Is unsafe code generally that much faster? : rust


Rust is the only mature, production-ready language that provides temporal safety without run-time mechanisms such as garbage collection or universally-applied refcounting, for large classes of code.

PDF from Secure by Design: Google's Perspective on Memory Safety


Another analogy I just came up with off the cuff:

The problem is that there's a LOT of empirical evidence that, no matter how well skilled individuals can write correct C or C++, people in groups cannot. Rust was designed to be the software equivalent to a lockout-tagout system. It protects you from changes you didn't see others making and vice-versa.

-- ssokolow @


In 10 years we went from “Rust will never replace C and C++” to “New C/C++ should not be written anymore, and you should use Rust”. Good job.

—dpc_pw @ Secure by Design: Google’s Perspective on Memory Safety | Lobsters


Looking back from this one year mark, we're happy to report that not only did we not die on the proverbial hill of learning Rust, the (much hyped) benefits of the language started materializing into tangible returns far sooner than we anticipated. While there is undeniably an upfront investment to learn Rust, by this point for us it has easily paid for itself many, many times over. Rust makes certain tasks easy that would have been exceedingly challenging in other languages. More importantly, our experience with Rust has turned out to be every bit as fun as we thought it would, and perhaps even increasingly so as we progress further on this journey:)


Great suggestion, but I think the article has a much better quote:


A visualization of the unsafe code that keeps me up at night.

edit: It is unfair to single out poorly-written unsafe code. Logic bugs also keep me up at night. And deadlocks. And a few other things that haven't been machine verified, yet.

1 Like

No human has ever done as much for rustc as bors has, because bors keeps things building, and it will stay that way. Even if bors does need the humans when it face-plants in the mud because of some iffy code.




panstromek: I remember reading somewhere (probably here) that borrow checking has O(n^3) asymptotic complexity, relative to the size of the function.

Nadrieril: Compared to match exhaustiveness which is NP-hard and trait solving which is undecidable, a polynomial complexity feels refreshingly sane.

Zulip discussion


This is going to show up here in some form or another:

Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.
- Lars Bergstrom, Director of Engineering at Google