TWiR quote of the week

Why use rust?

Rust is the ideal language to use if you want your code to be able to be compiled by the Rust compiler.


The goal of Rust is to have the power of C++ without the scary.


Wait ada is calling packages "crates" too?


Wow, seems they are.

A year or so ago I heard Ada was going to adopt some form of borrow checker inspired by what Rust achieves. I wonder how that to along.

Congratulations @dtolnay on being the first member of the "three comma club"!

I'm assuming this is the case. I haven't checked.


As the temporary human substitute for the temporarily unavailable automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

-- Mara Bos, wearing rfcbot's hat, in Tracking Issue for `Stdin::lines` forwarder method · Issue #87096 · rust-lang/rust · GitHub


I still get excited about programming languages. But these days, it's not so much because of what they let me do, but rather what they don't let me do.

From Some mistakes Rust doesn't catch by Amos.


Came here to suggest this. It absolutely captures the spirit of Rust for me.


rustc is just several HashMaps in a trenchcoat

From Gankra:

Or perhaps the full quote:

If you want to know more about the hashbrown (SwissTable) redesign, I wrote it up here a while back:

it was such an improvement that it reduced compile times for basically every rust program by ~10% (rustc is just several HashMaps in a trenchcoat)


From What does impl<’a> MyServer<’static> mean?


I'd like to suggest some part of this quote:


Due to recent events I feel the need to once again commend the reviewers and ehuss in particular for their amazing communication skills when reviewing PRs like this. I can only imagine how much work it means and how silly some of the changes proposed here might look to a seasoned cargo developer, yet you maintain a constructive, upbeat, and friendly spirit at all times. It's a style that I am aspiring when reviewing PRs myself, and is a prime example for the accessibility and friendliness of the Rust community as a whole.

Thank you!


Both because of how articulately Byron put the compliment and by how richly ehuss deserves it.


From Why raw pointer doesn't own type parameter T for dropcheck. Hilariously accurate.


A question #rustlang devs. What is the difference between String and &str?

Tim McNamara on twitter

one is for touching and one is for looking

Alexander Payne on twitter


protip: the rust extern keyword has a --help flag


source on Twitter


We can solve this with more violence threads

A problem we can solve with even more violence even more mutexes

From Request coalescing in async Rust -


Macros, right. Macros are cool, but like... Macros are great, in the hands of users, for letting users extend the language without having to actually go through and pester the devs and get a thing upstream. They let you extend the language in your own way in very small ways. But my opinion is that a widely used macro is kinda like a bug report against your language. ... You control the language, this is your language, just make it so I don't need this.

-- What's New in Rust 1.58 and 1.59 :: Rustacean Station (timestamp: ~6:00)


I don't like that quote. Isn't it supposed to be exactly the other way around? Macros exist so that the language doesn't have to be perpetually modified and bloated with every last thing people want. People will want different things because they come from all sorts of different backgrounds, and even when they want the same thing, there is going to be disagreement about implementation details, surface syntax, etc. Macros make that problem go away trivially.

"Just make it so I don't need this" is a daft thing to say, because doing things properly and generally enough so that it ends up being a useful and coherent part of the language is hard, but at the very least, it's a very slow and bureaucratic process. Why that would be preferable over just writing my own macro in the way I like, without inflating the language and imposing my own style upon everyone else in a way that ultimately nobody is really pleased, escapes me.

Considering specifically that the host is talking about format string "literals", and that there seems to be a consensus even amongst IRLO folks that fully-general string interpolation with embedding of arbitrary expressions is a Bad Thing™, this opinion sounds really unfounded to me. It's especially weird how he says at 07:09:

I just think that there are some cases where we can think about more regular solutions to certain problems.

This sounds incoherent, because macros are certainly more regular than giving every problem its own language feature. They are a conceptually unified way of performing metaprogramming at the syntactic level, no matter what the resulting code happens to be doing. That's in sharp contrast with writing a specific compiler pass for format strings, then another one for thread locals, then a third one for lazy initialization, and a fourth one for quantum flux frobnication.


That's exactly what the quote says. Macros are a good thing for users to be able to extend the language. The quote is just saying that if the language itself is providing a macro, perhaps we should just extend the language.

In this case, the quote was about the idea of replacing println!("{x} {y}") with println(f"{x} {y}"). I'm not necessarily saying we want to do that, but it seems like a reasonable argument.


Another quote from the same article:

As the popular saying goes, there are only two hard problems in computer science: caching, off-by-one errors, and getting a Rust job that isn't cryptocurrency-related.


I don't like this quote much either.

Firstly is it really true that macros are intended as a means of extending the language? I have never seen them that way. I see macros as a way of generating lumps of code to some formula to perform some common task. Stamping out code that cannot achieved by regular fixed functions.

Secondly it seems to be a call to start extending the language itself with all kinds of features people are doing with macros. The println! vs println() thing being an example of calling for veridic functions. This chills me to the bone, if Rust starts bolting on everyone's pet language features willy-nilly it will go the same way as the C++ behemoth and become totally unfathomable.

Please don't let that happen.