TWiR quote of the week

There actually are NOT very many places where the C code’s behavior conflicts with Rust’s borrowing rules. This is both somewhat surprising, because there’s no way this code was written with Rust’s borrowing semantics in mind, and also entirely sensible, since Rust’s borrowing semantics are often quite close to how you actually want your code to behave anyway.

Porting C To Rust


Not a rusty quote, but still nice:

There's two hard problems in computer engineering: cache invalidation, type naming and off-by-one errors

-- Arno Lepisk “Avoiding Disasters with Strongly Typed C++”


Sorry, that's very much not from this week :wink: See TwoHardThings for some history


Panic is "pulling over to the side of the road" whereas crash is "running into a telephone pole".

/u/zzzzYUPYUPphlumph on reddit.


I'd like to also nominate the full quote from the same source:

Panic is the car automatically pulling over to the side of the road, shutting down the engine, and refusing to restart when the blood-alchohol monitor detects that the driver is intoxicated and undefined behavior is letting things continue until the driver "crashes" into a bunch of school children in a cross-walk.


To be fair to @KillTheMule, that was added in an edit. (It wasn't there 8 hours ago when I went to bed.)


None of [Rust's] "safe" behaviors can lead to truly undefined behavior. ... If an attacker can only crash or deadlock your program, that's still bad, but it usually can't escalate into Front Page of the New York Times levels of bad.

Another one from the same thread, qualifying Rust's safety

1 Like

@withoutboats on internals

[It is] not only the systems programming problems that Rust tackles and makes accessible, but also the particular intersection of different expertises and goals - the systems problems, the type theoretical approach, the commitment to an accessible user experience - that [makes] Rust a fulcrum of learning for me. Even as my knowledge grows, there [is] always a more informed person - often a world class expert - available to answer my questions.


I’ve been very fortunate over these past 4 years to have had the opportunity to become more and more involved in Rust, to the point that now it is my full time employment. It makes me so glad to hear that my work has had for others the impact that the work of others before had on me.


From this blog post:

In Rust there are entire classes of bugs that are simply impossible to create because of the compile time guarantees. Because it’s software, there will be bugs. Oh yes, there will be bugs. However, we can create all new bugs and not trip over these other ones that we’ve been creating for the last four-plus decades.


This is the payoff, and despite the strictness of the compiler, Rust’s bet is that if you learn the way you can be as productive (or more) than with another language. In Programming Rust, Jim Blandy and Jason Orendorff refer to this as “Rust’s radical wager.”


I personally think this is kinda killer feature.


Undefined behaviour never was so nice! (Yes, I know that it's well defined by implementation, but doesn't this sound like it?)

Everything about Rust is ironic.


Who doesn't like building abstractions like LEGO :smile:

1 Like

This needs some more context. "It" here refers to "nested generic types". So:

[Using a nested generic types is] like building stuff with LEGO....

Not sure if you want to reference r/rustjerk in the quote but I post this anyways:

I've found that people who hate the borrow checker are usually ones that can't figure out why they always have so many weird bugs

by Inityx


Title of this reddit post:

"The Bug I did not have"

by u/pacman82


I'm batch-processing thousands of high-resolution TIFF images so these are processes that I start at the end of the day and let run overnight. I have multiple Java implementations that can do this; none of them perform at the same level as my novice Rust implementations.

From Reddit - Dive into anything


The security barrier must be earlier. It will make everything easier to secure. By analogy, it’s like securing your own house. You can lock points of entry to your house, and it’ll work fine for the entire house. But if you move the security barrier to wrong place because you assume burglars may freely roam inside your house, you’ll end up with locks on your bathroom, padlocks on your drawers, gates on your bed, TV stored in a safe, and kitchen utensils chained to walls.
Here, your OS is your house. If you work with assumption that you let malware in, and running viruses is normal part of Rust development, you’ll need extraordinary level of sandboxing paranoia similar to having things in your house chained to walls. It’s going to be incredibly hard to secure everything, and it’s going to be incredibly inconvenient to use the language that has to act at all times as if all your code was infected and dangerous.

original comment


A better approach is to make sure that there's no path from the guest bedroom to the master bath. :smiley: That means an OS should not be a monolithic whole, where penetrating any component gives full access to everything. For example, there is no reason why a network interface needs access to the file system, but that's exactly what an exploit from a couple of years ago used. What we need is isolation among the components of the OS. CapRos and seL4 are examples of how it can be done by applying the Principle of Least Privilege at a finer level of granularity than the whole OS.


[Rust's] unique selling point is that it unlocks a level of performance and flexibility that was previously not possible without investing in deep platform-specific knowledge and expensive quality assurance processes.

1 Like