TWiR quote of the week

Don't take away the fun part :-\

1 Like

Given that you're a team member, I'm going to push back on this quote as well. Not because bike-shedding is fun per se, but because community involvement is one of the great things about Rust.

The wider community may see problems and solutions a focused team do not, and have use-cases they haven't considered. The more language evolution leans towards fiat-by-team, the more concerned and frustrated I get. And I do feel it's increasing with time.


I don't know where the balance is between language design by one person or small team or design by contributions from a wide user base. C++ has a huge team of contributors, all be it members of the standards committee, which is huge, and see what a huge train wreck of complexity and incomprehensibility that has become.

workingjubilee on The assembly code generated by calling <[T]>::sort_unstable_by contains bounds checking code · Issue #92958 · rust-lang/rust

We're only concerned about producing high-quality garbage as fast as possible.


I present to you a humble limerick:

The language of choice was Rust.
The codebase would need to adjust.
’Cause a problem would come:
“Enum of None, Err, and Some?
A solution just is a must!”

-- MettiGrove @


Also, I don't know how much of this is because Rust is special or because BurntSushi is a national treasure and his CSV library is impeccably constructed and documented.


100% of Stripe's Ruby codebase, which is the largest single Ruby codebase in the world, is now autoformatted with Rubyfmt. We'll be upstreaming the changes we made soon. I'm very excited.

Rust helped make the fastest and most stable Ruby autoformatter in the world. We are 100% confident we would not have been able to work at the scale of Stripe's Ruby monorepo without the core being in Rust. So thank you @rustlang for making Rubyfmt possible.

1 Like

Now imagine using Rust to run actual server-side code instead of just formatting Ruby with it :sweat_smile:


Relevant in light of recent Mara's post:

Nothing about ISO or IEC or its various subcommittees incentivizes progress. It incentivizes endless feedback loops, heavy weighted processes, individual burn out, and low return-on-investment. Do anything – literally anything – else with your time. If you need the ISO sticker because you want ASIL A/B/C/D certification for your language, than by all means: figure out a way to make it work. But keep your core process, your core feedback, your core identity out of ISO. You can standardize existing practices way better than this, and without nearly this much gnashing of teeth and pullback. No matter how politely its structured, the policies of ISO and the way it expects Committees to be structured is a deeply-embedded form of bureaucratic violence against the least of these, its contributors, and you deserve better than this.


1 Like

I'm getting more convinced that Rust code is generally going to end up faster than C++ code every day I work on optimizations.

Strong immutability and no-alias guarantees are a game-changer and we've only really begun to scratch the surface of what can be done.

-- Patrick Walton on twitter


Is it too petty to nominate "I am aware of existence of C/C++ but those have old man smell" from /u/oiledupcucumber on What I like about rust : rust :laughing:


A couple of issues with that:

  1. It's blatantly ageist.

  2. Most developers of the C++ language are by no means old.

  3. Just because a thing is old does not not mean it's bad. Pythagoras theorem is still a great thing is it not?

All in all a pretty poor argument in favour of Rust. Rust has much better ways to make its case.


I think you are missing the point. The quote is about C and C++ being superseded by Rust. It's not against any person or group, and you have to interpret in its own context, which was given by the linked thread. Rust brought new developments to systems programming that cannot be retrofitted to C and C++, and that's a pretty damn good argument in favor of it.


But quotes are, by definition, taken out of context. Thus, regardless of how good it is in context, it's of questionable suitability for a QOTW.


I learned long ago, never to wrestle with the Rust compiler. You get dirty, and besides, the compiler likes it.

-- Adam Nelson paraphrasing G. B. Shaw on their blog


Meanwhile the Rust shop has covers on everything and tag-out to even change settings of the multi-axis laser cutter, but you get trusted with said laser cutter on your first day, and if someone gets hurt people wonder how to make the shop safer.

masklinn on Reddit


Rust would be better if it were written in Rust.

LLVM backend

Good news!

(wasmtime/ at main · bytecodealliance/wasmtime · GitHub)

"Aha, but std still has a libc dependency -"

(GitHub - bytecodealliance/rustix: Safe Rust bindings to POSIX-ish APIs)

"But the syscalls are still implemented in C -"

"But what about disk controllers, and firmware, and drivers, and everything else? Surely there isn't some way to completely avoid C?"

(from reddit)

1 Like

@lina @dougall While working on these userspace Mesa changes today, I did not hit a single GPU kernel driver bug. Not. A. Single. Bug.

This is thanks to Lina's phenomenal efforts. She took a gamble writing the kernel driver in Rust, knowing it would take longer to get to the first triangle but believing it would make for a more robust driver in the end. She was right.

A few months of Lina's Rust development has produced a more stable driver than years of development in C on certain mainline Linux GPU kernel drivers.

I think... I think I have Rust envy :crab:

....Or maybe just Lina envy :blush:


Regarding the friction you feel when writing embedded Rust in the same way you wrote embedded C++...


A fun little jab and hat tip to the Rust community...

I'm expecting this article to make the rust crew go in a crusade again, and I think I might be with them this time.