TWiR quote of the week

Little lengthy, but quite accurate.

Have you seen someone juggle several items with one hand? That's the point of async. Blocking (non-async) it like writing - it requires constant work from each hand. If you want to write twice as fast you'll need two hands and write with both at the same time. That's multithreading. If you juggle, the moment the item leaves your hand and is in the air, you have it left with nothing to do. That's similar to network IO - you make a request and are just waiting for the server to respond. You could be doing something in the meantime, like catching another item and throwing it back up again. That's what "await" does - it says I threw and item into the air, so I want my current thread / hand to switch over to catch something else now.

Source from the same user as last week!


don't worry: in 20 years we won't have Rust 2.0, but some upstart kid is gonna take all the lessons and mistakes we learned by then, make the Grime language, and slowly put us all out of work. Then we truly will be C++.

I can't wait for this day!

@Lokathor and @nikomatsakis on Zulip (archive)


Finally, I feel it is necessary to debunk the “ fighting the borrow checker ” legend, a story depicting the Rust compiler as a boogeyman: in my experience, it happens mostly to beginners and the 1% trying to micro-optimize code or push the boundaries. Most experienced Rust developers know exactly how to model their code in a way that no time is wasted fighting the compiler on design issues, and can spot anti-patterns at a glance, just like most people know how to drive their car on the correct side of the road to avoid accidents, and notice those who don’t!



I remember reading something from a coder who grew up on C, learned Rust, and the next time he had to write something in C, got really frustrated with all the bugs the compiler let through, since he then knew that it was possible to catch them at compile time.

That stuck with me and changed how I think about my fights with the borrow checker a bit.

/u/antichain @


We describe a lot of things as “how systems work” when really it’s “how C works” and part of Rust’s integration pains are just that it’s the first thing to credibly come into spaces and not fit in a C-shaped hole.


It's a great example of the different attitudes of C/C++ and Rust: In C/C++ something is correct when someone can use it correctly, but in Rust something is correct when someone can't use it incorrectly.


I think Rust is in an interesting place wrt specs because it straddles two kinds of language communities -- C/C++/JS, with serious specs and multiple implementations, and Ruby/Python/Go, with reference manual, a test suite, and a single canonical implementation.
Rust is a place where both of those traditions are being forced to reckon with the reasons why the other tradition exists.

Sam Tobin-Hochstadt on twitter


C binaries are smaller than rust, cars are lighter without seatbelts

-- Radomane in togglebit's chat


That's misleading, as Rust's safety has nothing to do with why the binaries are larger.


C binaries are smaller than rust, cars are lighter without seatbelts

I doubt that either of those statements is true.

Rust binaries can be really small. See what Cliff Biffle does:
On tiny micro-controllers: Rewriting m4vgalib in Rust - Cliffle
On web assembly: Making really tiny WebAssembly graphics demos - Cliffle

I'm pretty sure that many modern cars with seat belts are lighter than old cars without.
The "seatbelts" of the Rust language do not necessarily require adding code to the binary. Mostly not.

Besides, car analogies are always terrible. And the number of instructions required to do anything are not a function of the source language per se.


From Discord user Jarrett image:


cf. Rust Koans​​​​​


I think the security of the internet is incredibly important obviously and I want it to be secure and I think bringing rust there is absolutely going to help it. Just by default it eliminates some of the most classic types of vulnerabilities.

But I don't think that's the most exciting part. I think the most exciting part is that the set of people for whom it is possible to implement these types of things, like who writes coreutils, who writes curl, who does those things. That used to be a really small pool of people. That had to be people who knew the dark arts, and only them and only their buddies or something.

And it's the goal of rust to empower that to be a larger group of people and ultimately I think that that is what is going to happen which means the sheer number of people will be larger, and also the diversity of that set of people is going to grow. And I that that that will probably actually do more for the security and usefulness of these tools than eliminating underfined behaviour.

Ashley Williams on Free as in Friday (quote starts 46:48)


"Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED).

— Kornel, in Speed of Rust vs. C.


Whilst Rusts memory safety rules no doubt help greatly to prevent memory related security issues. I would not over sell the point.

It is still trivially easy to reuse a byte buffer for multiple purposes. For example to receive data into and then send that data elsewhere.

One of the first bugs I made in Rust was just doing a read into a buffer and then a write from the buffer. Forgetting the read might not filled the entire buffer and writing the entire buffer rather than the length that was read. Thus potentially sending sensitive data to the wrong place.

1 Like

In C it's perfectly rational to overuse linear search and linked lists, because who's going to maintain yet another half-assed implementation of hash table? There are no built-in containers, dependencies are a pain, so I cut corners to get stuff done. ... OTOH in Rust it takes only 1 or 2 lines of code to get very high quality implementations all kinds of containers. This means that my Rust programs can afford to use proper, incredibly well-optimized data structures every time.

— Kornel Speed of Rust vs. C


Do we permit gifs?

if a rustacean says something about an "invariant lifetime" in response to your question, it is too late, there is no escape, you are now one with the crab


This is just to say,
I have rebased
the feature branch
opened against

and which
you might have been
already working
on fixing

Forgive me,
the diff was so trivial
so minor
so smol

-- Jubilee on rust-lang zulip


Given Linus's well known position on C++ in the kernel (for those who are not familiar with it, imagine five minutes of swearing, followed by "Over my dead body"), this is practically a warm welcome.

-- lurgi on /r/rust


Reddit done gone 503.

This is a better link:

1 Like