3 ms·
There's a common theme in posts like this where the writer knows _too much_ about programming, and tries to do things that are awkward in Rust, but a lot of the
by empath75 2y ago
There's a common theme in posts like this where the writer knows _too much_ about programming, and tries to do things that are awkward in Rust, but a lot of these problems don't actually come up in practice. Sometimes I feel like they take it as a personal challenge to never ever use .clone() and like -- it's okay -- use clone(), nobody else is going to know.
I'm maintaining 4 kubernetes operators written in Rust with a team of devs who are _not_ brilliant developers, and it's all async, and once I setup the patterns, they were able to jump in and start contributing business logic immediately.
Is it the most performant possible implementation? Definitely not! But once I told them how to stop using unwrap() everywhere, they have literally _never_ crashed or panic'd in over a year. When we were working in go, nil pointer exceptions were the bane of our existence.
- osigurdson 2y agoI always thought that using Rust for Kubernetes controllers / operators would be going against the grain a little (since almost everything in that ecosystem is golang). I'm interested in why your team ended up switching to Rust and how it is working out for you.
- bnpxft 2y agoAt the risk of making this another Go vs Rust comment, I hesitate to mention this, but Go developers copy structs all the time. We do it mostly as a way to make values immutable (and to avoid nil checking all the time). It is mostly not a problem. If something is a hot path, we'll use a pointer. Whenever we pass by value as opposed to by address, Go makes a copy. Use .clone() in Rust, it is fine most of the time. Optimize it out if you find it is a performance bottleneck. https://go.dev/play/p/Cm7mzRbva-5 https://go.dev/play/p/Cm7mzRbva-5
- arwhatever 2y agoI am hard-pressed to think of a context in which .clone() is better-suited than in business apps.