TWiR quote of the week

Rust was built by a secret society of Haskell developers to teach programmers how to use monads.



We could absolutely link to it, and we could quote the text (since it's not like any of the other quotes are licensed under an Open Source license), but I don't think we could embed the image without license issues.

I'd propose linking it separately, and not making it the quote of the week.


"I have to say contributing to Rust way less scary than I expected with all the people answering questions"


This forum is licensed under the CC-BY-NC-SA.


From a conversation started by a new user learning Rust for the first time.


I appreciate this summary of Rust's (de facto) ideology:


About heap allocation.


‘My biggest compliment to Rust is that it’s boring, and this is an amazing compliment.’


On Why the developers who use Rust love it so much:

"It feels like being part of a village that learns to love the dragon it battles."

-- turbinerneiter on Hacker News


Perhaps one solution would be to quote that alt-text and just have a link to the image?

Pretty long quote from u/0xdeadf001short version:

The borrow checker is like the Shaolin kung fu master [...]

Long version:


Rust's beauty lies in the countless decisions made by the development community that constantly make you feel like you can have ten cakes and eat all of them too.

-- Jake McGinty et al on the tonari blog


References are a sharp tool and there are roughly three different approaches to sharp tools.

  1. Don't give programmers sharp tools. They may make mistakes and cut their fingers off. This is the Java/Python/Perl/Ruby/PHP... approach.
  2. Give programmers all the sharp tools they want. They are professionals and if they cut their fingers off it's their own fault. This is the C/C++ approach.
  3. Give programmers sharp tools, but put guards on them so they can't accidentally cut their fingers off. This is Rust's approach.

Lifetime annotations are a safety guard on references. Rust's references have no sychronization and no reference counting -- that's what makes them sharp. References in category-1 languages (which typically do have synchronization and reference counting) are "blunted": they're not really quite as effective as category-2 and -3 references, but they don't cut you, and they still work; they might just slow you down a bit.

So, frankly, I like lifetime annotations because they prevent me from cutting my fingers off.

-- @trentj When do you find lifetime annotations helpful? - #6 by trentj


Rust is like a futuristic laser gun with an almost AI-like foot detector that turns the safety on when it recognises your foot

-- goofbe


Ownership in Rust is entirely a type system fiction.

-- @RalfJung [Brainstorming] Is there a body of research on ownership equivalent to Stacked Borrows

I'm not sure what is meant there. "ownership" in many languages is a very real thing to me.

For example in C++ you might create an object and then you have a pointer to it. At some point you have to "free" that object else you have a memory leak.

You might pass that pointer around to other functions and threads in your system. At some point someone has to "free" it. But who? Not necessarily the creator of the object. Hopefully at least the last user of the object, else you have a dangling pointer reference.

One has to take account of this ownership problem when building a C++ program to avoid big problems. Even if the language itself does not have a way to express ownership. Similarly for other compiled languages. Heck, even assembler.

AI are fallible. I would say it's a property of space-time that makes the distance infinite between any gun and any foot. You need to build unsafe wormholes to bypass it.


I misread this as "Ownership in rust is type science fiction" - and for me that's bang on the money. Rust programming is sci-fi except it's here now.


My understanding is that "Ownership in Rust is entirely a type system fiction." is a fancy way of saying that, if you look at the generated machine code, you can't "point at the ownership".

It's purely a constraint on which programs will be allowed to compile, similar to how machine code has no concept of variable types. They're just constraints in the compiler so you can't accidentally call the floating point addition opcode on bit patterns representing integers without first specifying how to reconcile the two.