9 ms·
I'm the author of the blog post. The focus of the article really is about JNI in Rust. I see most questions are about "Why did you not use X language instead?
by amunra__ 3y ago
I'm the author of the blog post.
The focus of the article really is about JNI in Rust.
I see most questions are about "Why did you not use X language instead?", so let me try and address this.
To answer the "Why not just Rust", I should first mention that Rust was still in its early days (before 1.0), and it was a risky bet to choose an emerging language.
The project was started by Vlad (our CEO) who had a background writing high performance Java in the trading space. The Zero-GC techniques - whilst uncommon in open source software - are mature and a staple of writing high performance code in the financial industry. The product evolved organically, feature after feature.
I personally joined the team from a C and C++ background, having previously moved from a project that suffered from minute-long compile times from single .cpp files due to template overuse. Whilst I do miss how expressive high-level C++ can be, Java has really good tooling support.
When writing systems-style software most of what matters in terms of performance is how we call system calls, manage memory and debug and profile. This is an area where Java really shines. Don't get me wrong: In the absolute sense I think C++ tools tend to be better (Linux Perf is awesome!), but Java tooling is _there_. IntelliJ makes it trivially easy to run a test under the debugger reliably and consistently. It's equally easy to run a profiler and to get code coverage. The same tools work across all platforms too, might I add. It's not necessarily better, but it's easier. Turns out that while a little quaint, using Java turned out to be a pretty good choice in my opinion in practice.
Times have moved on. The Rust community really cares about tooling, and it's one of the reasons why we've picked it over expanding our existing C++ codebase: We just want to get stuff done and have enough time left in our dev cycle to properly debug and profile our code.
- belter 3y agoThanks for the interesting post. Do you plan to maybe use in the future JEP 442? https://openjdk.org/jeps/442 https://openjdk.org/jeps/442
- amunra__ 3y agoWhen the time is right. There's finally new APIs coming in the Java space that will make native-code interop easier and more reliable. Our open source database edition can also be used embedded though, so we can only upgrade at the pace of our customers and because of that we still are compatible all the way down to Java 8. Were it not for this detail, we'd probably consider it a lot sooner.
- ahoka 3y agoSo Rust combines the expressiveness of C++ with the ease of development of Java?
- kaba0 3y agoI wouldn’t call Rust easy to develop in.
- mcronce 3y agoI would
- cmrdporcupine 3y agoIt's like skiing (or maybe riding a bike for the first time.) Steep learning curve then becomes somewhat instinctual and fairly routine and trivial and fun. Until you get into the tricky terrain, and then it will put up resistance. But usually for your own good.
- neoCrimeLabs 3y agoRolling with the analogy, I think learning rust a lot more like snowboarding, and C/C++ is more like learning to ski. I fell a lot more learning on snowboard than on skis. Skis had a much quicker early learning curve, and made me feel over-confident. Several times I found myself on trails too steep for my skills, and the skis made me have to work hard to recover. Most of the techniques I learned as a beginner didn't work beyond green trails, and blues, blacks all required new, harder, techniques. With snowboarding, because I fell a lot more early, my confidence slowly grew. Meanwhile the techniques I was learning on the greens, and the tool in general, that were HARD to learn on the greens were actually EASIER on the blues, and continued to work on the black-diamonds. Granted I also had to learn new techniques on the harder trails, but the beginner techniques and the slower development made me MUCH more confortable across the whole mountain much faster than skis. Double-blacks are more like unsafe rust. :-D
- cmrdporcupine 3y ago
- lenkite 3y agoWhy did you not consider leveraging Java's recent Foreign Function and Memory API ?
- bluestreak 3y agoOne of our distribution channels is Maven Central where we ship Java 11 compatible library. Embedded users preclude us from leveraging latest Java features.
- Yeroc 3y agoFYI, even in the most recent Java (21) LTS release this is flagged as an "early access" feature so you're unlikely to see production applications using it yet.
- HdS84 3y agoDo you know ravendb? Document db almost entirely written in c#. It's incredible how fast it can get, but as you said it does not look like typical lob code at all
- goostavos 3y agoDo you have any background reading for high performance java or how it's used in the finance world? I had no idea it was used in this niche. As a crufty Java dev who types `new` everywhere and never gives thought to GC, squeaking out high performance sounds like an interesting side of the language.
- amunra__ 3y agoMaybe we should write a blog post, though there's gotta be one out there for this already. The short of it is: Learn C. Learn your system calls. Learn JNI. Learn about com.sun.misc.Unsafe. Learn about the disruptor pattern. Learn how to pool objects. The long type can pack a lot of data. Go from there!
- Yeroc 3y agoCheck out Peter Lawrey's blog [1] has lots of excellent content coming from high performance trading background. Also some older (probably dated) content on Martin Thompson's Mechanical Sympathy [2] blog. [1] http://blog.vanillajava.blog/ http://blog.vanillajava.blog/ [2] https://mechanical-sympathy.blogspot.com/ https://mechanical-sympathy.blogspot.com/