I think the Postel's Law thing is interesting, and wanted to talk about it, but it's a bit off-topic, so I posted my reply as a Gist instead.
I'm not sure it's concise enough to be a good QOTW (the relevant part is four paragraphs), but The Good > Performance
in Two Years of Rust is the most satisfyingly argued expression I've yet seen of the problem with pervasive slowness in languages.
(The whole thing is beautifully insightful. For example, I've never had something about workspaces resonate as much as The Bad > The Module System
and, as such, despite having been writing Rust since literally the day the v1.0 stability promise came into effect, I've avoided workspaces so hard that seeing lines like "and don’t forget to set publish = false
in the Cargo.toml" are less "I relate to that" and more "I'm going to chop this post up and put pieces of it in my basket of reference materials".)
The problem with Rust is that it achieved memory safety by sacrificing the sanity of the programmer.
"What Language was before C": https://www.youtube.com/watch?v=gS_jY8iPBv8&list=TLPQMjAwNDIwMjWZ1biMOqpJbA&index=5
Every sufficiently advanced test is indistinguishable from a game engine
_cart (creator of bevy) on Reddit
I think the comment preceding that should go along with that quote:
https://www.reddit.com/r/rust/comments/1k721w1/comment/moumd91/:
With Bevy clearly being an extended test suite for Rust's trait solver, how did you get the idea to also turn it into a game engine?
https://www.reddit.com/r/rust/comments/1k721w1/comment/mouzde0/:
Every sufficiently advanced test is indistinguishable from a game engine
Vivek: Well, the answer is basically yes. Our firmware is all Rust. Every component of our autonomy stack is Rust. Our app is 50% in Rust. And, our visualization tools are in Rust. Our production tools are in rust. The production QC software, which we ship to China, is in rust. Our internal websites are in rust. It's rust all over. We’ve drank the Rust Kool-Aid. In fact, there is no Python installed on the robots. This is not to dis Python at all, but it’s just simply not there.
Vivek: We use Python for neural network training. But Python is boxed to that. Everything else is Rust. And, the advantage of using Rust exponentially builds up.
From this week's Rust lang meeting, while discussing https://github.com/rust-lang/rust/pull/140638:
That’s not a Pin, that’s a Pun!
10 I don't understand Pin
20 Read explanation of Pin
30 I understand Pin
40 Read explanation of Pin
50 Go To 10
/proc/self/mem is outside the scope of rust's safety guarantees. otherwise this would open a can of worms that could not be closed except by forbidding debuggers from poking memory or marking every impure function as unsafe.
like, what if you invoke gdb to poke memory? what if you modify .bash_profile to poke memory? what if you send an http request to a hypervisor to poke memory? what if you run a spin loop, and the noise of the fans whirring up activates a beam of ionizing radiation pointed directly at the CPU? what if opening the disk drive makes the computer fall off a cliff?
When commenting about a blog post that argue that learning Rust as a first language from someone who already knew other programming languages
This is basically the programming version of "learning Japanese as an English speaker is hard, therefore it is not a good language for babies to learn"
By u/Aaron1924 on reddit
A bit of context: the rav1d Rust rewrite of the orginal C dav1d AV1 decoder has offered a 20k reward to make it has fast as its C counterpart
“Rust is so good you can get paid $20k to make it as fast as C.”
A cheeky comment by ffmpeg folks, reported by Ryan Dows in Rust developers offered $20k for rav1d to reach C performance
Of course the goal of the reward is to understand why there is a performance difference between the two languages and how to fix it.
Of course the goal of the reward is to understand why there is a performance difference between the two languages and how to fix it.
...and, so far, posts like Making the rav1d Video Decoder 1% Faster are turning up things like "the default choice for a constructor zeros this memory but the humans can tell it will never be read before the inline assembly fills it" and "derive(PartialEq)
doesn't currently implement the 'comparing two consecutive u16s as a single u32 as a performance optimization' trick in situations where it's safe... possibly because it can't guarantee that property will hold universally".
Interesting stuff.
Probably better to link to the original x.com post:
I think Rust is an excellent gamedev language. I like that it allows users to comfortably walk up and down the stack, all in one language (you can write very low level code and very high level code). It allows us to build Bevy using the same apis that developers use to code their games (which is uncommon in the "big engine" space). The tooling is top notch, as are the community and ecosystem. Game engines are (or at least ... should be) very multithreaded things, and Rust is excellent at "fearless concurrency". I also appreciate the async support, and I think it is largely the right fit for us.
There are certainly things that could be improved, both on the Rust side (partial borrows, variadics, stable Rust ABI, etc) and on our side (more "access whatever data you want without worrying about conflicts" apis) to make the gamedev experience smoother. But those are all being worked on. I don't have any regrets about my choice to use Rust. Bevy wouldn't be what it is today if it was built in another language, and I think what it is today is pretty special.
- u/_cart on https://www.reddit.com/r/rust/comments/1kt03fc/bevy_jam_6/
The reach for best practices is understandable from the perspective of “I would like to have somebody who knows tell me what to do before trying it.”
But I think that that is searching for safety in a way that isn’t particularly necessary, because at some point that best practice is just somebody’s opinion about how you should do things, from having done it a bunch of times. Hopefully having done it a bunch of times!
And you could be the person to do it a bunch of times.
- Chris Biscardi on "Back from RustWeek! Character controls in Bevy" live-stream
https://youtu.be/Jm8O-MNPDUc?t=6572
I think this quote is sarcastic/derogatory, not flattering.
Rust-based Python type checkers are like buses - you wait ages for one and then two come along at once.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing
Mathewson 6:31
(citation also re-used in parking-lot-ffffffffffffffff)
But after a few weeks, it compiled and the results surprised us. The code was 10x faster than our carefully tuned Kotlin implementation – despite no attempt to make it faster. To put this in perspective, we had spent years incrementally improving the Kotlin version from 2,000 to 3,000 transactions per second (TPS). The Rust version, written by Java developers who were new to the language, clocked 30,000 TPS.
This was one of those moments that fundamentally shifts your thinking. Suddenly, the couple of weeks spent learning Rust no longer looked like a big deal, when compared with how long it’d have taken us to get the same results on the JVM. We stopped asking, “Should we be using Rust?” and started asking “Where else could Rust help us solve our problems?”