"Rust is basically Haskell's athletic younger brother. Not as intellectual, but still smart and lifts weights."
-- icefox, Jan 22, in Discord chat #games-and-graphics channel
TWiR quote of the week
11 Likes
In context, I'm guessing the user intended that as a criticism. I think having criticisms as quote of the week is fine, but this one seems likely to be misinterpreted as praise.
2 Likes
I've started associating a shower of warnings with "success", because those only appear once all the errors have been taken care of
-- brundolf, on compiling rust code
7 Likes
People argue about the color of a bike shed because even though it's a meaningless decision - it's still a decision that has to be made. The null choice is a very bad choice - if you don't paint the shed it'll rust. And there is no "default color" so you can't just say "just color it" - you have to pick a color.
Even seen someone argue about the pattern of the shed's paint? No. The pattern is not any more meaningful than the color, but unlike the color - there is a null choice. There is a default. Solid paint. And because there is a default, no one even thinks about using something else because why are you wasting company time and money on a pattern for a bike shed?
From my personal experience, when there is a default and the default is good enough, nobody bikesheds how to derive from the default. They only discuss it when there is a concrete problem with the default, where is doesn't fit your needs for whatever reason. And when you do have a concrete reason to derive from the default - you will derive from the default. Because you have to. And if the library does not support it - you'll switch the library.
-- /u/somebodddy on when opinionated design succeeds or fails to prevent bikeshedding
14 Likes
5 Likes
When chatting about using async in an internal project my colleague shared a funny quote over chat:
2021 is supposedly the year of the async Rust desktop
For context, we were fighting with getting blocking code integrated with non-blocking since we wanted to do it incrementally.
5 Likes
Whoa there, you mean there is effort underway to solve the "red function / blue function" problem?
"https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
That sounds truly awesome.
1 Like
Taken from io_uring presentation by Tyler Neely:
I can accept code in pull requests with a small fraction of the mental energy as I would need in auditing C/C++ due to compiler's strictness
7 Likes
The consistency angle really shouldn’t be overlooked. Performance is nice, but slow and consistent can still be planned for much more easily than inconsistent.
That was the big aha moment about Rust for me when I pushed out my first project using the language. Being nervous about it I had added way too much instrumentation so that I could know how every bit of it was responding to real traffic. But as soon as I started seeing the data, I was convinced that my instrumentation code was broken. The graphs I was seeing were just so...boring. Straight lines everywhere, no variation...after 24hrs, the slowest response (not P99...literally P100) was within 75ms of the fastest response.
-- tablair @ https://www.reddit.com/r/rust/comments/eytyug/why_discord_is_switching_from_go_to_rust/fgjjpiv/
(Especially that "But as soon as I started seeing the data, I was convinced that my instrumentation code was broken.")
8 Likes
Rust developers, on the other hand, are used to taking a lot of coffee breaks (or tea, cigarettes, sobbing, or whatever as the case may be — Rust developers have the spare time to nurse their demons).
-- @brson's tongue-in-the-cheek reference to Rust's compile times in https://pingcap.com/blog/rust-compilation-model-calamity/
4 Likes
Rust's predictable performance lands another strike for the team! 
Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go.
[..] After a bit of profiling and performance optimizations, we were able to beat Go on every single performance metric . Latency, CPU, and memory were all better in the Rust version.
Discord Engineer Jesse Howarth, in the blog post
"Why Discord is switching from go to Rust" (emphasis in original)
This Discord Blog documents tangible productivity benefits, improved performance, as well as platform maturity for Rust, great things for our community to show in 2020!
Also, the more predictable behaviour allowed them to increase cache-sizes without suffering catastrophic GC-spikes, leading to a factor-5 to factor-200 improvement, depending on the metric (the graphs are a bit too low-res to get more accurate numbers).
9 Likes
go [or Rust] style package management tools are designed to build programs that work. Not programs that work on Debian if you have the right libs installed, or on Windows 7 or newer, or whatever, but “if you compile it on an OS, it works on that OS”.
6 Likes
It's a safe system programming language which just happens, unlike something like Ada, to have a critical mass of hipsters and webdevs behind it.
-- RAKtheUndead on why Rust is so popular @ https://www.reddit.com/r/MechanicalKeyboards/comments/f2o7vu/a_handwired_unsplitted_ergo_keyboard_with_a/fheeltk/
(You've gotta at least grin at reading that.)
9 Likes
That is encouraging. Back in the day C and Unix were said to be promoted and spread by "hippies" from Berkeley. Sounds like Rust in on the right track then.
Another thing we should remember when talking to other-language folks:
14 Likes
Some time later the tax man comes by. He asks to see my tally sticks from last year. Oops, now I have a problem! I need records, databases, immutable data structures, extra book keeping work. Incidental complexity.
What am I missing in my shepherds tale?
Your analogy is quite good, but I don't think it unambiguously supports mutable data structures.
The abacus will let you count faster, but is a bad medium for long-term storage. A stick with notches isn't exactly immutable, since you can cross over notches, so in a sense they're mutable but only additively. If you glue the beads of the abacus it becomes better than a stick with notches for bookkeeping but worse for counting.
You can evaluate data structures outside of computers perfectly fine like this. I would even say that this isn't figurative speech or metaphor: We're actually analysing the time and space complexity of real-world data structures. Once we get to von Neumann-style computers, the materials (RAM, CPU, etc.) just have a different cost profile which make some analogical comparisons break down a little.
A very strong property of immutable data is that you can refer to it from other data and know that it won't eventually become invalid. So immutable data can be used to annotate other immutable data (or other mutable data, for that sake, but then this recursive property is instantly lost). This is the bookkeeping part.
The radical idea of using functional or otherwise declarative programming for general purposes (rather than very domain-specific ones) comes from the observation that often the cost of immutable data structures is well within acceptable limits of our materials. And because computer programs often do a mixture between counting and bookkeeping, you get the benefits of persistency at more levels.
When the cost of immutability is too high, Haskell has come up with the ST monad, which is a type-safe way to mutate a value locally. When the cost of mutability is too high, Rust has come up with borrowed types. These notions may essentially express the same machine-level operations.
Whether you decide to complicate your program with "pure data" or "linear types", the justification is in both cases that more constraints will provide for more efficient compilation and execution strategies, at the cost of mental overhead to the programmer. So if you think e.g. linear types are worth pursuing, you're probably closer in mindset to a purely functional programmer than you think, sans the extremist attitude. 
2 Likes
So, Rc<RefCell<T>> is "Shut up, I don't care", while unsafe is "Shut up, I know what I'm doing"?
4 Likes
I wouldn't say that.
Sometimes it really is the right tool for the job, but it often gets abused by people used to having a GC where it's okay to hand out references like candy.
unsafe on the other hand can be thought of as the pragmatic escape hatch you sometimes need to use when doing things which are, well, unsafe... That doesn't roll off the tongue nearly as nicely as you put it though...
2 Likes
most of the quotes in this thread are very positive and sometimes funny, but looking at the original post from feburary 2015 above, we're supposed to also submit "insightful" stuff. so i guess the following one qualifies, even though it's kind of sad.
The number of crates which can be charitably described as a " barely functional list of the author's opinions wrapped around a project's c-api " is mind numbing. Picking a crate for a new problem domain is like walking through a mine-field. It feels like (when official options are not available) I need to dedicated ~3-4 weeks to just selecting and patching the dependencies I'm going to use for a project so I can be responsibly confident in them.
-- valarauca14 on reddit thread titled What do you miss about other languages when working in Rust?
7 Likes
on a more ironic note, there's also
& * 'a &'a Box || macro! mod crate extern crate #[...] String vs &str &self unwrap expect ? Rc Arc
by new community member @yjoking on this thread