4 ms·

> 1. Unless you abuse Rust horribly, it is both memory-safe and fast The fact that you don't mention computational complexity as the primary concern here tells

> 1. Unless you abuse Rust horribly, it is both memory-safe and fast The fact that you don't mention computational complexity as the primary concern here tells me that there is something wrong with programming as of 2024. And not necessarily with Rust per se but maybe all the other languages. Why should humans bother with anything else than choosing the right algorithm for the task? And possibly not even that. It should be "combine X with Y such that i get Z" Rhetorical question. I know I open up for many counter arguments, so please choose wisely to keep the discussion alive. And maybe it is just as simple that Rust is the answer to that question?

DarkNova6 3y ago
That's fair criticism. I was writing this under the pretense that you get the basics right and don't have needless garbage between you and CPU execution. There's also the fact that Rust tends to draw those who are already proficient with computational knowledge. Whereas the typical Python programmer is just a poor dud that never had any formal education in accessing computer resources.
- fifilura 3y ago
  So if i loop back to the original message "Written in Rust", what they mean to convey is that "this is done by smart people" ;)
  - DarkNova6 3y ago
    You jest, but if we are talking average it would not be hyperbole. But what I want to add to my last point: Most performance pitfalls I have seen are not due to choosing wrong algorithms, but bad implementations driven by messy implementation and low maintainability. Python and JS are absolutely among the worst of the bunch and weak dynamic typing is a terrible burden to maintain and scale. Mind you, it depends on which domain we are talking about. If you are working close to the metal and you are using something like PyTorch, your performance is indeed determined by choosing the right algorithms and language overhead is less significant in comparison. But most software is just moving things around in memory and do a little networking.
zellyn 3y ago
There are times when the right algorithm dominates, and you end up using something written in a language that doesn't fit your expertise/deployment system/preferences/etc. because it's the only thing that implements a particular thing well. There are a lot of great tools like Redpanda (C++) where there isn't a memory-safe alternative filling the same niche. But as a professional programmer for 25 years now, I'd say the fraction of our job that boils down to finding, designing, or implementing the right algorithm is sadly tiny. It's all the messy details that end up soaking our time and attention. One way to increase the amount that algorithms matter is to work at greater scale, which is basically why I moved from "programming at some corporation that does something else" to Silicon Valley technology companies. The other important detail is that different languages allow for very different kinds of refactoring. I've found the Oxide and Friends podcast to be possibly the most powerful vote of confidence in Rust that I've ever seen in this regard. In their most recent episode -- https://oxide.computer/podcasts/oxide-and-friends/1734108 https://oxide.computer/podcasts/oxide-and-friends/1734108 -- they discuss how Rust allowed them to make sweeping and rapid structural changes to their storage code that they wished they could have been able to do in the underlying layer -- ZFS. (This from folks who helped create ZFS or were at least adjacent.) If your language allows you to make sweeping refactors safely, it enables you to mutate your code towards better algorithms for the task. Also, it can give you more time to focus on the algorithms. If I, a novice C++ programmer, allowed to actually use C++ in anger, I'd spend all my time trying to figure out memory safety and ownership problems, not focus on the algorithms. I'm simply not willing to put in the multiple years of hard work it would take to be able to program C++ safely. But I'd be willing to let myself, a novice Rust programmer, use Rust. It might not be pretty, and the borrow checker and I might come to blows, but it wouldn't be dangerous. (fwiw, I'm really a Go programmer. But I've lurked many programming languages and their communities during their early phases (Go, Rust, Zig, Roc, Perl6), and it's hard to argue that Rust is _really_ good at certain things.)

DarkNova6 3y ago

That's fair criticism. I was writing this under the pretense that you get the basics right and don't have needless garbage between you and CPU execution. There's also the fact that Rust tends to draw those who are already proficient with computational knowledge. Whereas the typical Python programmer is just a poor dud that never had any formal education in accessing computer resources.

fifilura 3y ago
So if i loop back to the original message "Written in Rust", what they mean to convey is that "this is done by smart people" ;)
- DarkNova6 3y ago
  You jest, but if we are talking average it would not be hyperbole. But what I want to add to my last point: Most performance pitfalls I have seen are not due to choosing wrong algorithms, but bad implementations driven by messy implementation and low maintainability. Python and JS are absolutely among the worst of the bunch and weak dynamic typing is a terrible burden to maintain and scale. Mind you, it depends on which domain we are talking about. If you are working close to the metal and you are using something like PyTorch, your performance is indeed determined by choosing the right algorithms and language overhead is less significant in comparison. But most software is just moving things around in memory and do a little networking.

zellyn 3y ago

There are times when the right algorithm dominates, and you end up using something written in a language that doesn't fit your expertise/deployment system/preferences/etc. because it's the only thing that implements a particular thing well. There are a lot of great tools like Redpanda (C++) where there isn't a memory-safe alternative filling the same niche. But as a professional programmer for 25 years now, I'd say the fraction of our job that boils down to finding, designing, or implementing the right algorithm is sadly tiny. It's all the messy details that end up soaking our time and attention. One way to increase the amount that algorithms matter is to work at greater scale, which is basically why I moved from "programming at some corporation that does something else" to Silicon Valley technology companies. The other important detail is that different languages allow for very different kinds of refactoring. I've found the Oxide and Friends podcast to be possibly the most powerful vote of confidence in Rust that I've ever seen in this regard. In their most recent episode -- https://oxide.computer/podcasts/oxide-and-friends/1734108 https://oxide.computer/podcasts/oxide-and-friends/1734108 -- they discuss how Rust allowed them to make sweeping and rapid structural changes to their storage code that they wished they could have been able to do in the underlying layer -- ZFS. (This from folks who helped create ZFS or were at least adjacent.) If your language allows you to make sweeping refactors safely, it enables you to mutate your code towards better algorithms for the task. Also, it can give you more time to focus on the algorithms. If I, a novice C++ programmer, allowed to actually use C++ in anger, I'd spend all my time trying to figure out memory safety and ownership problems, not focus on the algorithms. I'm simply not willing to put in the multiple years of hard work it would take to be able to program C++ safely. But I'd be willing to let myself, a novice Rust programmer, use Rust. It might not be pretty, and the borrow checker and I might come to blows, but it wouldn't be dangerous. (fwiw, I'm really a Go programmer. But I've lurked many programming languages and their communities during their early phases (Go, Rust, Zig, Roc, Perl6), and it's hard to argue that Rust is _really_ good at certain things.)