Hi, I don't go as much into lower-level details as many people on this list, but I have been trying to write machine sympathetic code for a few years now, and I am using Rust in production.
Most notably I wrote some performance-oriented Java code (a distributed DB/data processing platform) a few years back and had to implement a bunch of stuff in a garbage-free manner, unsafe and other shenanigans to get adequate performance on heavier queries (running through multiple GBs of data). The data management/processing system performed well but I had to jump through hoops and the trade-off was that parts of the code were difficult to maintain. The networking part was not very satisfying because of well-documented limitations in NIO... Looking back, I have no regret choosing Java for that project because there was no valid alternative, C++'s complexity is really a productivity hit IMO (even with modern C++ though it has improved). If I were to take the same decision today, I would not hesitate to use Rust instead. I have jumped ship to Rust a bit more than a year ago and I am mostly writing distributed services using Tokio and async/await. The system does not do heavy data processing but I can see how the Java project could have been written in Rust instead in a much clearer, more maintainable way. Arguably (minimal?) value types could also fix part of the issue, but as they are an ad-hoc addition to Java I am not sure they will ever feel as native as structs are in Rust, and Java's type system is bare compared to Rust's. As for performance, I am confident a rewrite could outperform the Java version because Rust opens many more doors compared to Java. The networking stack and async ecosystem in Rust (mostly Tokio) is simply excellent. The perf is great, it's always possible to get to syscalls and change something "below" when it's needed (without JNI overhead), and async/await makes it easy to read and write async code as if it were sync. The community still tries to isolate protocols from side effects/temporal coupling and builds them in a "Sans IO" approach (e.g quinn, a Quic implementation). This is made easy by the type/trait system, inspired by Haskell, which helps composability greatly. Compared to C++, Rust exposes many fewer knobs -- which is great for 99% use cases but can sometimes prevent to customize some semantics (e.g move cannot be customized, it's always a memcpy, which may or may not be optimized by LLVM). In exchange, the limitations provide greater opportunities for generic optimizations (with respect to aliasing, struct packing, etc). Having memory unsafe operations explicitly annotated helps code reviews drastically (and every day code can be fully written in safe Rust) which is a great productivity boost compared to C++. Also, by statically verifying lifetimes and the absence of data races, Rust programmers don't need to fall back to "safe/common patterns" as much, and can use the stack much more. It's easy to avoid most allocations, which in general makes Rust programs super cache-friendly and balances other slow downs. Even compared to Java or other memory-safe languages, the static data race detection and the lack of uninitialized state makes writing thread safe code much, much easier, and the richer type system (and absence of `null`) helps build models with many more compile time invariants (and that helps reviews and team productivity). I also particularly lack the openness of the community, which is a big change compared to the "us vs them" feeling I had with JVM vs Java developers. This lets applications developers participate in the language development. We're running in production with these services and they have been very stable and robust. I am positively surprised by the maturity and stability of the Rust toolchain and ecosystem considering how young it is. I guess this is a tribute to the great language decisions but also to the mixed academic + hacker culture that exists in Rust, in the sense that Rust did not ignore either the last 30 years of language research, nor the state of the art in industry languages (e.g Cargo, the build system is very modern and a breathe to use). This is a virtuous circle as it is drawing many younger talents into Rust, who in turn help improve the ecosystem. In that regard it reminds me a lot of the early years of Java. The lack of runtime (whether it's the JVM or static GC runtime like in Go) helps with predictability and the costs of learning the language are more upfront. The JVM is great engineering but it's also very complex and tuning it for different applications is a rare skill and an endless rabbit-hole. These are different, valid, trade-offs, but I have been very satisfied by Rust's approach there (automatic memory management, no GC, good benchmarking tools, and predictable performance). Last but not least, Rust's reputation as a difficult language is IMO outdated, as the latest edition has a borrow checker able to do much deeper program analysis and does not require much/any programmer help to prove that borrows are valid anymore. I have personally started writing serious Rust *after* this landed in nightly and I haven't "fought" the borrow checker. I would say that Rust does have a learning curve, but once it's passed it's actually easier to write code because there are much fewer invariants to keep in mind, since they are either natively checked by the compiler or easily encoded through types (as zero-cost abstractions). I am casually writing code in Rust I would never dare write in C++ (because there would be bugs in the code or the way it's called, or it would be too hard to maintain), and that I couldn't write in Java without JNI. Simon Vitaly Davidovich a écrit le 09/10/2019 à 04:19 :> I posed this question to this list a few years ago, but don’t recall > much participation - let’s try again :). > > Has anyone moved their C, C++, Java, whatever low latency/high perf > systems (or components thereof) to Rust? If so, what type of > system/component? What has been your experience? Bonus points if you’re > running this in production :). > -- > Sent from my phone > > -- > You received this message because you are subscribed to the Google > Groups "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37FLx5-4m9Bx%3DuLA3CWkk7JmqbUzRd5M0rSq2nk1XeR9rQ%40mail.gmail.com > <https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37FLx5-4m9Bx%3DuLA3CWkk7JmqbUzRd5M0rSq2nk1XeR9rQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/46d2afe1-c584-51ed-776e-ca3e2d385da9%40gmail.com.
