There's premature optimisation, where you write a whole bunch of complicated code to avoid cloning an Arc<>. And then there's "premature optimisation" where you skip any consideration for performance until it becomes a problem.
The latter is usually what people who use the quote "premature optimisation is the root of all evil" think it means. Don't just keep calm and clone, consider what you're cloning and why, and then hopefully we won't end up with even more horribly slow software.
"Keep calm and clone" is a good advice for beginners. Then it is also a good advice for experts - because when you're an expert and you just think of cloning, that probably means it is easier than borrowing which you would default to.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Notice the aspects and the reasons for knuth's "premature optimization". Is it making the code harder to debug and read? Is it a non-critical path?
If an optimization doesn't impact readability or debugability (for example, picking a datastructure that fits the problem instead of just using a List for everything). Then you should do it.
I see the quote so often pulled by people that want to justify inserting a n^2 algorithm when a log(n) solution is either the same amount of code or 1 line extra.
There's also important context about the era knuth was programming in. Optimization in the era of knuth was targeting the hardware and tickling things like the CPU cache and memory in a very specific way. It was things like clever bit manipulation and packing to save memory. That's the context. In modern terms it'd be "don't use SIMD intrinsics until you know you need them". It wouldn't be "Don't think about algorithmic complexity" which is where I most often see that kludge deployed.
The question to me in terms of memory is, if you're writing a weather app on windows why are you not using C#.
The point of these low/zero overhead languages like Rust is you're in an environment where memory management is ultra critical. The dotnet garbage collector does more than a good enough job for a weather app, likely a much better one than vibe coded .clone() Rust
Instead of oscillating between Rust and 1 GB webview apps just ... use the excellent managed language that exists on the operating system appropriate for GUI applications?
Now that WinUI has a Rust API, I think using Rust is a no-brainer.
The app will be running on probably about a billion of devices, and Rust will reduce the footprint on each of those - assuming not a vibe coded clone app.
The additional effort isn't that big, and it would make the experience of maaaany users a bit better still.
Now extrapolate on all windows included apps and ui elements.
Maybe they fired all their experienced developers and only have cheap vibecoders now, I don’t know. The decisions of beancounters and lawyers that control these companies are mysterious to me.
The things that unsafe enables are arbitrary pointers, FFI, and accessing union members in a C struct. It seems highly unlikely to me that unsafe would fix any beginner's problem.
.clone() on the other hand is indeed an easy/quick fix for a lot of issues you'd face when learning rust.
I think beginner programmers are unlikely to use unsafe when learning rust but people coming from c or c++ who are beginners at rust might use unsafe all over the place.
Exactly - we have been using C or C++ for decades and most of us have a lot of experience. We think like programmers in the languages meaning we often do things that Rust won't allow without unsafe. A small percent of the time that is the right thing (which is why Rust have unsafe), but very often there is a Rust way that is just as performant if only we knew how to think like Rust programmers.
Sadly it still feels like it's one of the languages where the language doesn't trust you, it tries to force you to do things "the right way". I do love quite a few of its design like how traits are, not forcing every method into the declaration, and the standard library is much less crazy than the C++ version.
Sadly, other things a bit less so - the story for the thin battery-less stdlib + npm-style churn encourages bloat, and the semantics are obsessed with safety at a heavy cost to productivity unless you spam clone() and reference-counting - but then your program becomes slow, kind of negating the advantages, you might as well have written it in C# or something...
Yeah it doesn’t trust you, and for good reason the decades of developers making the same mistakes over and over again. If everyone was perfect you wouldn’t need Rust, but no one is perfect and that’s why Rust exists.
Yes, but this this is not a problem at all because any bug caused by misuse of unsafe (or unwrap) is entirely the fault of the programmer (or the AI) and not of Rust. /s
This argument applies regardless of how you feel about vibecoding. Lately people have been asking for x64 machine language and getting reasonable results.
The question in terms of memory is, will vibe coded rust get around ownership issues by .clone()-ing everything.
Maybe this has changed since I wrote Rust, but that was a classic beginner fix. Just throw memory at it.
https://github.com/luser/keep-calm-and-call-clone
"Keep calm and call clone" is a good strategy for getting things working. Don't prematurely optimize code until you know it's the bottleneck.
There's premature optimisation, where you write a whole bunch of complicated code to avoid cloning an Arc<>. And then there's "premature optimisation" where you skip any consideration for performance until it becomes a problem.
The latter is usually what people who use the quote "premature optimisation is the root of all evil" think it means. Don't just keep calm and clone, consider what you're cloning and why, and then hopefully we won't end up with even more horribly slow software.
"Keep calm and clone" is a good advice for beginners. Then it is also a good advice for experts - because when you're an expert and you just think of cloning, that probably means it is easier than borrowing which you would default to.
By all means use borrowing if it's straightforward. But don't necessarily upend your whole codebase to avoid one clone, either.
Isn’t the latter what Knuth meant?
Such a slippery slope between “consideration of performance” and optimization.
The full quote
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Notice the aspects and the reasons for knuth's "premature optimization". Is it making the code harder to debug and read? Is it a non-critical path?
If an optimization doesn't impact readability or debugability (for example, picking a datastructure that fits the problem instead of just using a List for everything). Then you should do it.
I see the quote so often pulled by people that want to justify inserting a n^2 algorithm when a log(n) solution is either the same amount of code or 1 line extra.
There's also important context about the era knuth was programming in. Optimization in the era of knuth was targeting the hardware and tickling things like the CPU cache and memory in a very specific way. It was things like clever bit manipulation and packing to save memory. That's the context. In modern terms it'd be "don't use SIMD intrinsics until you know you need them". It wouldn't be "Don't think about algorithmic complexity" which is where I most often see that kludge deployed.
The question to me in terms of memory is, if you're writing a weather app on windows why are you not using C#.
The point of these low/zero overhead languages like Rust is you're in an environment where memory management is ultra critical. The dotnet garbage collector does more than a good enough job for a weather app, likely a much better one than vibe coded .clone() Rust
Instead of oscillating between Rust and 1 GB webview apps just ... use the excellent managed language that exists on the operating system appropriate for GUI applications?
Now that WinUI has a Rust API, I think using Rust is a no-brainer.
The app will be running on probably about a billion of devices, and Rust will reduce the footprint on each of those - assuming not a vibe coded clone app.
The additional effort isn't that big, and it would make the experience of maaaany users a bit better still.
Now extrapolate on all windows included apps and ui elements.
How much would that cost per license?
Maybe they fired all their experienced developers and only have cheap vibecoders now, I don’t know. The decisions of beancounters and lawyers that control these companies are mysterious to me.
The other things I've seen beginners do is throw unsafe at everything.
The things that unsafe enables are arbitrary pointers, FFI, and accessing union members in a C struct. It seems highly unlikely to me that unsafe would fix any beginner's problem.
.clone() on the other hand is indeed an easy/quick fix for a lot of issues you'd face when learning rust.
I think beginner programmers are unlikely to use unsafe when learning rust but people coming from c or c++ who are beginners at rust might use unsafe all over the place.
Exactly - we have been using C or C++ for decades and most of us have a lot of experience. We think like programmers in the languages meaning we often do things that Rust won't allow without unsafe. A small percent of the time that is the right thing (which is why Rust have unsafe), but very often there is a Rust way that is just as performant if only we knew how to think like Rust programmers.
Sadly it still feels like it's one of the languages where the language doesn't trust you, it tries to force you to do things "the right way". I do love quite a few of its design like how traits are, not forcing every method into the declaration, and the standard library is much less crazy than the C++ version.
Sadly, other things a bit less so - the story for the thin battery-less stdlib + npm-style churn encourages bloat, and the semantics are obsessed with safety at a heavy cost to productivity unless you spam clone() and reference-counting - but then your program becomes slow, kind of negating the advantages, you might as well have written it in C# or something...
Most of the time the rust way is just as good, just different.
Yeah it doesn’t trust you, and for good reason the decades of developers making the same mistakes over and over again. If everyone was perfect you wouldn’t need Rust, but no one is perfect and that’s why Rust exists.
Yes, but this this is not a problem at all because any bug caused by misuse of unsafe (or unwrap) is entirely the fault of the programmer (or the AI) and not of Rust. /s
Actually they just Arc<T> everything
Instead of leaking memory it'll just clone the whole heap over and over.
I seriously do not think things could be any worse.
If it's vibecoded, who GAF what language is used?
This argument applies regardless of how you feel about vibecoding. Lately people have been asking for x64 machine language and getting reasonable results.