You won’t appreciate Rust unless you spend few weeks building something in it. The initial steep learning curve could be frustrating or challenging depending on how you see it, but once past that it’s hard not to love it. It’s a toddler with superpowers after all
Deepu K Sasidharan on My second impression of Rust and why I think it's the best general-purpose language!
I often think about Rust as a process and community for developing a programming language, rather than as a programming language itself.
throwaway894345 commenting here (The Plan for the Rust 2021 Edition | Hacker News)
They were responding to
Rust isn’t only a great language, it’s a model of how technology can be built.
asimpletune
Because I can:
This time, there were two crates and one quote, which is not much, but ok. Keep it up, folks!
"Low level" is a lie created by Big Level to sell more levels. Anything you can do in C++, you can do in Rust.
https://reddit.com/comments/nkm89x/comment/gzdivcv
reddit user K900_ giving the ultimate answer on "Is Rust as low level as C++ and C"
I recently graduated with my Ph.D., after having worked on 5 different versions of my simulator, written in 4 different languages. The last version, written in pure, safe rust, worked correctly in part because of rust's strong guarantees about what 'safety' means, which I was able to leverage to turn what would normally be runtime errors into compile time errors. That let me catch errors that would normally be days or weeks of debugging into relatively simple corrections. [...] So, once again, thank you to everyone!
As the tradeoffs in software engineering change over time, so does the ideal solution. Some 40 years ago when the first C standards were written down, by people no less competent than those that work on Rust today, the design of the language and the list of behaviours not defined likely made much more sense in context of back then than they do right now. It is not all that unlikely that some years down the line the choices made by Rust won't make all that much of sense as they do today, too.
@nagisa in Why deference MaybeUninit().unint().as_mut_ptr() is safe? - #19 by nagisa
If manually managing memory is like wielding a gun, the borrow checker is an automatic safety that prevents you from pulling the trigger when you're roughly pointing it at yourself. But it's coarse-grained and errs on the side of caution; it simulates your foot as as the rectangular box that would contain it, not as a detailed 3D mesh. If you really think you can aim it between your toes and avoid hitting yourself (for example, "the value returned by this function must remain alive for no more than 15 successive invocations of this function"), unsafe will let you try, but the borrow checker's built-in rules isn't granular enough to help you, though it will still stop you if you accidentally put your hand in front without declaring it.
infogulch on HackerNews comments for The memory models that underlie programming languages (2016)
TBH I find "coarse-grained" a bit of a stretch. Without further context, the quote sounds as if the borrow checker was usually not really useful and had to be worked around, except for the most trivial cases. Whereas in reality, it's the exact opposite – needing to unsafe one's way around a borrow checker usability "bug" is – and should be – extremely rare.
Maybe a better metaphor would be that the borrow checker won't let you fire at targets smaller than the cone of uncertainty without a backstop to catch the bullet.
from Julien Tinnes' blog: cr0 blog: A few thoughts on Fuchsia security
For system-level folks, Rust is one of the most exciting security developments of the past few decades. It elegantly solves problems which smart people were saying could not be solved.
Fuchsia has a lot of code, and we made sure that much of it (millions of LoC) was in Rust.
Our kernel, Zircon, is not in Rust. Not yet anyway.
Go loses its memory safety guarantees if you write concurrent software. Rust loses its memory safety guarantees if you use non-trivial data structures. C++ loses its memory safety guarantees if you use pointers
David Chisnall on lobste.rs
I don't agree. We can use Rc<RefCell<T>>/Weak<RefCell<T>> and then indeed lose compile-time memory safety, but we usually instead use unsafe code and encapsulate it in crates. There are tons of crates for complex data structures, and they have very strong memory safety guaranteed.
C++ doesn't have any memory safety guarantees at all 
There's at least an explanation needed here. This is simply not true as-is in the absence of unsafe, and many non-trivial data structures can in fact be implemented without unsafe.
From Freeky on reddit
At last, I can name my unsafe functions appropriately.
unsafe fn e͙̤͎̪͒x̲͓̞̤͍̻̺̂͗͛͆͡t̜̣͊̓ͩ̍̑e̩͖͙͎̼̖͉ͮṇ̨͖̎̓ͅd̗̼͕ͫ̅_̲̦̥̙̙͍͂́l͙͙̦̞̠̃͌͒i̹̘͍̳̊ͪͦͤ͒̊͋f̨ͥ̄̌ḛ̜͗̉̃̎̂̔̐t̩̲̘͕͉̺̫̓͗́i̹̤̭ͭ͆̔ͪͤ͢m̹̤̜̗̫̩͍ͨe̝͒ͣ<'b>(r: R<'b>) -> R<'static>
It's better to do:
unsafe fn extend_lifetime<'a, 'b>(r: R<'a>) -> R<'b>
Because it works better with generics (and you can always return to the above signature by specifying 'b == 'static.
No need to discuss the API, this quote is all about the unholy diacritics on the identifier.
I needed to double check but apparently, this identifier is actually literally valid.
Well, it gives a warning at least
warning: identifier contains uncommon Unicode codepoints
Linux Fortune: (full text)
What they say: What they mean:
Meets Tough Quality Standards It compiles without errors.
Ok this was not about Rust. It was a joke about languages like C. But with Rust, it's true!