Stop Whining about Rust Hype – A Pro-Rust Rant

Stop Whining about Rust Hype – A Pro-Rust Rant
thenewwazoo.github.io

I've yet to find a good toolkit/framework that helps me build web apps. I stick to JavaScript merely because it's a language that allows me to do most of what I want, in a tolerable way, in most situations, on both the client and server.

But, I know the problems with it. And there are a lot.

Is there a toolkit for building web apps that has the ergonomics of something like Svelte? Or, at least is a toolkit that radically simplifies building things in the client with wasm?

Until I find that, I'm just going to stick with JavaScript, only because it's more important for me to ship quick prototypes than build something perfect before I know what that is.

As someone who likes Rust, it takes days or weeks to wrap your head around the borrow checker, and "spaghetti object graph" code patterns in other languages don't transfer well to Rust (Cell is more awkward to use than C++ int, and RefCell introduces runtime panics). I've had the misfortune of dealing with code written in unsound unsafe Rust which freely converts aliased raw pointers into &mut, even when they likely conflict with other & or &mut. I still don't know how to rewrite it in safe Rust.

Rust is built around making mutable multiple ownership awkward. This is fine (and often results in more understandable code) when you're working in single-ownership code conceived and built around Rust, but when you're using something like gtk-rs (which binds to a C framework built around reference counting and cyclic parent pointers), Rust makes mutating shared state awkward (adding extra state alongside GTK widgets requires RefCell or similar), and reference-counted callbacks awkward (the clone! macro breaks rustfmt).

> Nobody thinks you’re smarter or better because you can remember all the pitfalls.

Oh, I know some people who think that way. Personally I think Rust teaches you the same things as C++ code (reasoning about state, knowing what parts of your code reference an object, knowing when to free an object).

> Soon your solution won’t be faster to market, and will be more expensive to maintain to boot. And someone’s going to eat your lunch while you complain.

There's no Rust GUI framework as comprehensive and mature as Qt. (Then again, there's no C++ GUI framework as clean, usable, and stable as Qt should've been. And people are moving to web UIs.) And some (not all) Rust libraries are amateurish from people who don't know what they're doing; for example, https://lib.rs/crates/samplerate allocates on every conversion (which isn't safe for real-time audio generation) rather than writing into a preallocated &mut buffer. https://docs.rs/hound/latest/hound/ is a WAV file reader which branches on every sample (IDK if it gets optimized out), rather than performing error checking at file open time and bounds checking once per block, which feels bizarre to me.

Re. "An ability to compensate for the shitty state of technology" that exists today isn’t some kind of a competitive “moat”.", writing your own bindings to C code, or performing unsafe C calls directly, instead of using the ergonomic libraries which don't work properly, is compensating for shitty technology.

IMO this article comes pretty close to flamebait and trolling.

Lifetimes are hard.