The language ends up doing a random walk via small steps through the design space without a coherent long term vision, because nothing else is feasible.
I think using the full paragraph might give people a bit more context:
I don't necessarily agree with all their design goals, but it is unfortunately true that getting a large coherent change through the C++ committe is an herculean task. The language ends up doing a random walk via small steps through the design space without a coherent long term vision, because nothing else is feasible.
Monad: Design pattern in which pipeline implementation are abstracted by wrapping a value in a type
By "A bit of code" in the video what is a monad (design pattern).
Note that this quote was not about Rust but since the word "monad" is regularly used a lot in Rust, and it was a very nice and concise explanation, I’m still submitting it.
Another quote that wasn’t created by Rust folks by which is very relevant when writing fast Rust code.
The key to making programs fast is to make them do practically nothing.
By Mike Haertel in why GNU grep is fast (2010).
JuSt Be CaReFuL
If there’s one lesson from decades of software engineering, it is the failure of “just be careful” as a strategy. C/C++ programmers still experience memory corruption constantly, no matter how careful they are. Java programmers still frequently see
NullPointerExceptions, no matter how careful they are. And so on. One of the reasons that Rust is so successful is that it adds automated checks to prevent many common mistakes.
By the author of the blog Considerations on Codecrafting in Fixing the Next Thousand Deadlocks: Why Buffered Streams Are Broken and How To Make Them Safer.
100,000 issues filled with love, compassion and a wholesome community. Thank you, Rust community, for being one of the most, if not straight out the most, welcoming programming communities out there. Thank you, Rust teams, for the tireless hours you spend every day on every aspect of this project. Thank you to the Rust team alumni for the many hours spent growing a plant and the humility of passing it to people you trust to continue taking care of it. Thank you everyone for RFCs, giving voice to the community, being those voices AND listening to each other.
This community has been and continue to be one of the best I have ever had the pleasure of being a part of. The language itself has many things to love and appreciate about it, from the humane error messages to giving the people the power to express high performance code without sacrificing readability for the ones to come after us. But nothing, truly nothing, takes the cake as much as the community that's building it, answering questions, helping and loving each other. Every single day.
Congratulations everyone for 100,000 issues and PRs! And thank you for being you. Because Rust is Beautiful, for having you as part of it.
To the times we spent together and the many more to come!
Issue #100000 in the rust-lang/rust repo.
I expressed basically the same sentiment in What is the biggest difference between Garbage Collection and Ownership? - #24 by H2CO3
Don't come empty-handed to a project saying "this could be rewritten in Rust". It's obnoxious and gives the rust community a bad name.
Do start the project on your own, adding Rust to the build system and converting some significant functions, and then ask the project's community for comments.
From Rust in Perspective by Linus Walleij
The ambition of Rust is, as I perceieve it, and whether the people driving it even knows it or not, to finish what the ALGOL committe as primus motor started in 1958, and what the Garmisch NATO conference concluded was necessary in 1968: to develop a language for systems programming that rely on formal logic proof, and to fulfil what ALGOL never could, what Pascal never could, and what the whole maybe-not-700 functional programming languages never could: a language that joins the disciplines of computer science and software Engineering into ONE discipline, where the scholars of each can solve problems together.
Or if the above is to long, another quote from the same article:
TL;DR: my claim is that Rust is attempting to raise the abstraction in the programming language and ultimately to join computer science and software engineering into one single discipline, an ambition that has been around since these disciplines were created.
The core difference is that Rust directly represents the concept of lifetimes in its type system. The borrow checker is part of the compiler, not part of the human.
(Not particularly novel, but I've never seen it said so elegantly before.)
...and one of my own I just came up with, where I found the metaphor I stumbled onto particularly appealing:
This all sounds like more complexity introduced by (and avoided by not) hammering a
Mutex<T>peg into a
(Or, given that it's about padding, I suppose no hammering would be needed since
Mutex<T>would be the round peg with a diameter smaller than or equal to the length of a side of the square hole. Like a sabot for your footgun.)
A fast executing language that crashes all the time is like a supercar… that crashes all the time.
Rust is weirdly all-level programming language. You literally can have pointer arithmetic, iterator transformations, and inline python macro back to back in the same function.
If your code is expected to be a bottleneck in terms of CPU usage, memory usage, latency or bug-fixing, then Rust is a very strong contender. It can save you money and effort in the long run.
From Pinecone's "Inside the Pinecone" article on their transition from Python, C/C++, and Go to Rust, by Edo Liberty (bold emphasis mine):
[W]e reached a tipping point. We decided to move our entire codebase to Rust... . Rust seemed to give us all the capabilities we needed, however, there was still one minor problem - no one on the team knew Rust. ...
We started with a small team of senior engineers and managers learning Rust and developing the skeleton of the DB and dev environment (for others to build on). Then, slowly, others joined in rewriting and contributing different components until we eventually got rid of the old codebase altogether (I still remember the day my original C modules, from the first days of Pinecone, were taken out). Unbeknownst to most Pinecone customers, the new Rust core was deployed in March this year. And in the process of taking over running workloads, we managed not to drop a single API call!
... We all expect[ed] performance and dev processes to improve. Those indeed happened. What we didn’t expect was the extent to which dev velocity increased and operational incidents decreased. Dev velocity ... improved dramatically with Rust. Built-in testing, CI/CD, benchmarking, and an overzealous compiler increased engineers’ confidence in pushing changes, and enabled them to work on the same code sections and contribute simultaneously without breaking the code base. Most impressively though, real time operational events dropped almost to zero overnight after the original release. Sure, there are still surprises here and there but, by and large, the core engine has been shockingly stable and predictable.
Thank you very much! It's good to see another Rust user who understands that true skill in the art comes not from idiomatic code, or from building relations with the community, but rather from the number of references to the
Pintype that a developer feels comfortable making.
From the community that brought you the Pre-RFC and the e-RFC, we now introduce: the de-RFC!
Make sure to check out the creatively named section headings in the actual rendered contents, too .
So long, and thanks for all the turbofish.
https://www.reddit.com/r/rust/comments/wzuoqz/comment/im4pek6/ , in response to the deprecation of RLS
In Rust We Trust
GATs incresses the overton window of what one thinks is possible. So, a forcing function indeed.