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.
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.
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.
4 replies →
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.
5 replies →
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.