Morestina

This is the first of a series of three blog posts, with quite an interesting conclusion in the final post[1]: > On my 2012 desktop workstation with 3GHz Xeon W3550, the Java benchmark reports an average of 7.3 ns per getTransformed invocation. The Rust benchmark reports 128 ns in get_transformed, a whopping 17 times slower execution. [...] This article was written five years ago and things may have changed for better or for worse. However, this is an obvious example of how using Rust can make your code slower: by making you implement all the nitty-gritty details yourself (i.e. multi-threaded locking mechanisms), getting everything right and up to speed is left up to you rather than to the standard library, like in Java, where dedicated people have been improving their solution to this problem for decades now. Rust can be lightning fast compared to Java but it's worth considering using the "slower" alternative for certain workloads (in this case, many cross-thread operations) to get a performance benefit. All the talk about Rust's fearless multithreading does not necessarily make it a good language, merely a less correctness-bug-prone alternative to C++! I've run the benchmarks on my machine with an up-to-date Rust install; to prevent library bugs, I've also upgraded Rusts's dependencies to the highest level they'll go. For the Java samples, I'm running Java 18 with the default GC (haven't set up 19 yet on my machine). The results are kind of wild. On the Rust side, the…

First it was "Rust's async isn't f#@king colored!" (https://www.hobofan.com/blog/2021-03-10-rust-async-colored/) Then "Rust async is colored, and that’s not a big deal" https://morestina.net/blog/1686/rust-async-is-colored And now it's a good thing. Honestly, this sounds like somebody struck Achilles' heel of Rust and it hurts. They're neatly covering 3 stages of grief over these 3 articles, and I wouldn't be surprised if we could uncover the other 2 in the blogosphere somewhere.