6 ms·
The problem is essentially that nobody ever evaluates how good their code is, they evaluate how much better it could be. Code that has an Arc<Mutex<>> around e
by pie_flavor 4y ago
The problem is essentially that nobody ever evaluates how good their code is, they evaluate how much better it could be.
Code that has an Arc<Mutex<>> around every single type in Rust could be made a lot better. Code that does the same in Java could not, because Java doesn't have the ability to make types not wrapped in Arc<Mutex<>>. If you wrote perfect code in Java, it would be equivalent to Arc<Mutex<>> code in Rust - which is not hard to write at all, presenting minimal annoyance. Lest I be lambasted for comparing to a JIT language, that's also how everyone writes C++ these days, and for the same reasons.
But that's not how anyone looks at code. They see the ability to unbox types. They see the ability to borrow instead of moving. They see the ability to modify stuff in place instead of making it immutable and then deep-copying it. In most cases the code to do so is shorter and easier. In some other cases, it's longer and more difficult. And people exclusively look at the latter cases, the fact that it's difficult to further improve past what they previously thought of as perfection, and declare Rust to be Hard™, and go back to Java where they can attain perfect code, even if it's worse than the Rust equivalent.
Like nerd-sniping, except you do it to yourself.
- jstimpfle 4y ago> even if it's worse than the Rust equivalent. If the Java version does the same thing, but with less typing and unnecessary fluff, then it is indeed better.
- felipellrocha 4y agoIt isn’t, though. The point is that you *can* write it without thr Arc<Mutex<>> and gain significant speed without it. Even if your first iteration started with it.
- thaneross 4y agoTo add to this point, even if you season your Rust code liberally with Arc<Mutex<>>, the libraries you use probably don't, and you'll still get most of the performance benefits.
- athrowaway3z 4y agoNo its not. The quality of a abstraction dictates how clear you are able to think about things. 'Less typing and unnecessary fluff' is the difference between writing '100' in Arabic numerals or writing 'C' in roman numerals.
- dgb23 4y agoIf we're being pedantic then the Rust version is not an abstraction at all. It explicitly states how exactly the object is de-allocated and how it is accessed. In the Java version, which is definitely not just an Arc<Mutex> but something more opaque and powerful, you let the runtime handle and optimize these things for you, because you really don't want to know. It would only get in the way of the essence of your program, because your program is decidedly not about expressing these things. Well at least the Arc, the Mutex part is not necessarily much better. So it's not '100' vs 'C' but more like '100 apples' vs 'enough apples'. Both have their upsides and downsides. It certainly is a good thing that both expressions exist.
- athrowaway3z 4y agoI like your '100 apples' vs 'enough apples' because it highlights a fundamental choice. The first is a statement that stands alone, whereas the second is a statement requires knowledge of the target/problem you are referencing. My guess is that in the long run the first is more successful. It doesn't require consensus about a target/problem. However, there are enough places who couldn't care less because everybody knows what enough apples are.
- Karrot_Kream 4y agoNot everyone values this the same and this is where a lot of preference wars start in PL communities. Some people enjoy keeping the problem space small and having opinionated decisions at the cost of limited expressiveness. Others value expressiveness maximally. This [1] article goes into a lot of the tradeoffs involved with expressivity and cognitive load (with the background of how being a PL enthusiast tends to color one's thoughts). [1]: https://scattered-thoughts.net/writing/things-unlearned/ https://scattered-thoughts.net/writing/things-unlearned/
- kaba0 4y agoAnd Java is much faster than some hypothetical Arc<Mutex> only Rust, as (atomic) RC is quite slow.
- dataangel 4y agoC++ wrapped in Arc<Mutex<T>> is not at all how people write C++ nowadays. There are some (poor) code cases where people slap shared_ptr on everything, but even then I've never seen them also also mutex on everything. That's just terrible practice.
- tasn 4y agoI couldn't agree more! I often tell the team something similar: if you struggle with ownership or getting some code to work, you can always just clone and get the first draft working. You'll still do better than the equivalent in Python or the likes.