Possible Java to Rust switch for a securities trading platform

I was close. Thanks for the correction!

1 Like

I’m also in the HFT space. We use Rust but not yet as ambitiously as you are proposing. The language won’t stop you producing solid reliable low latency code; but the ecosystem might.

The quality of crates is high just because the language generally ensures things are largely bug free; so you do get a level of trust above that of other languages. Rust follows a fail-fast model and is (largely) enforced at compile time so you’ll catch most bugs, technical and business at dev time. At least if you don’t catch it, it will usually have unwrap() call next to it.

The threading model is rock solid and you will be able to try threading in places where you would not dare in other languages as the compiler will stop you making mistakes. But in the HFT space you’ll want single threaded systems to minimise latency I would have expected?

Where you will fall down, is in GUI, databases and other “enterprise” items. It’s not there yet. Then language and tooling is ok but I have high hopes for 2018


Just to clarify we are more of in the market making space rather than HFT. You and Vlad are right about having a single thread occupying a CPU core processing fast orders from a queue but we also have other house keeping stuff + multiple subscribers to our service where threads come into play. And every thing needs to be very very fast. For e.g. a core feature would be non blocking, contention free/less queues into which multiple threads are reading and writing. (Think similar to lmax disruptor https://github.com/LMAX-Exchange/disruptor) We have our in house java libraries for this kind of stuff + other utilities such as working with money and object pooling etc. These libraries even though not perfect still are quite mature.

What has your experience been regarding creating lots of new objects ? Have you observed any memory fragmentation issues ? Or do you do object pooling?

The relative maturity of libraries in Rust specially comments such as ‘language isnt mature enough’ by the fix-rs guys isnt very comforting. As this is my personal project atm I dont want to go down a rabbit hole and waste time.I think this would need a bit more thinking on my side to be able to wrap an existing fix engine such as quickfix into a Rust wrapper maybe…

Has anybody tried go-lang for this kind of stuff? how does the real world performance of go-lang compare to Rust ?


Close - Vitaly :slight_smile:

All of Java, C, C++, Rust, etc will use pools/arenas for the allocation rate you were mentioning before. Even if you had an allocator that is 100% fragmentation resistant, you would incur various latency stalls going through it so many times. So all systems in this space will work hard at avoiding that.

The fix-rs author mentioned the following reasons for suspending development:

Long compile times is self-explanatory. I wish he'd gone into detail on what exactly was poor about the networking libraries (mio at that time, presumably - although maybe he's talking about tokio as well). However, I'd be particularly interested in the last one: difficulty eliminating allocations while keeping ergonomics. It's too bad he didn't elaborate (or did he and I missed it?).

I don't have 1st hand knowledge but I suspect it'll be largely comparable to what you'd get with Java. Go fails on the type system strength front, however. And there's still a GC to worry about, albeit Go gives more control to do stack allocations.

Just my $.02

@vitalyd sorry about getting your name wrong and thanks for your $.02 which is probably worth £20 or some thing after brexit :slight_smile:


Hi @alinaqvi90

For your question on allocations and objext pooling, in rust it’s very explicit if you are doing any heap allocations or copies. Because of this I find that 95% of the time objects are stack allocated in rust and you go out of your way to avoid copies.

In that case your object pooling and fragmentation issues are non existent.

Where you do use memory pools is whenever I see Vec::new(). It usually tells me it’s worth looking to optimise with a pool allocator or similar.

For threading I’ve used channels and atomic ref counted objects. Again it’s so rare and with such short locks you really do get excellent performance. I’m experimenting with co-routines but haven’t quite figured it out it, but that would be a win for your network/io.

A million objects at once? Probably fine using a pool and with deterministic deallocation you won’t get the GC kicking in at inadvertent times.

The language is mature but there are some bits missing that would really help (they are coming in 2018) in the hft space that I’m looking forward to. They are const generics which would reduce allocations even more, streaming iterators to avoid copies from files, networks, better Simd

I wouldn’t consider it “not ready” by any means, and you’ll be ahead of the curve of you start now


My understanding is const generics and generic type constructors (needed for streaming iterators) are unlikely to ship in stable Rust this year, unfortunately. Of course I may be wrong and time will tell but that’s the takeaway I had from reading some of the 2018 roadmap.

Are you aware of any efforts of making something like Seastar for Rust?

If you squint, tokio + futures has some overlap, at least from the async futures-based API on top of a reactor perspective. Seastar, however, has more features, including dpdk integration.

So overall, there’s nothing like it that I know of.

It’s probably already been mentioned, but it cannot be overstated how much better JavaFX is than anything Rust has to offer right now.

Dear Rustaceans,

I’ve learned Rust lately and I like it :slight_smile: I came across your comments looking for practical ideas for next project.

It’s been a while since I worked for Credit Suisse and True Trade. @vitalyd @gilescope @jimuazu and rest, I’m looking for your advice about what might be a promising experiment to start with :slight_smile:

Summary as it seems to me

  • Port lmax disruptor? (have non blocking, contention free/less queues into which multiple threads are reading and writing)

  • pick up where fix-rs left off?

  • improve infra/lower level stack Rust story (PoC trading system from scratch? following seastar + DPDK) @BuddyCasino interested?

  • co-routines experment for network/io

I can dedicate upto 20 hours per week to experiment like that for a couple months or so to come. I am hardcore. I hacked on Solaris kernel; wrote scalable Bitcoin matching engine in Erlang; wrote MSIL interpreter in Prolog which can run backwards and more :stuck_out_tongue:

Looking forward for your suggestions!

1 Like

How's your progress, @alinaqvi90 ? Need help?

tokio-tungstenite works quite well if you’re connecting via WebSockets.
As well as Fix there’s the binary Fix that a lot are switching to.

A good friend of mine wrote a very fast fix parser in unidiomatic Java which was a testament to what can be achieved with Java if you try realy hard to avoid the GC ( https://github.com/gsitgithub/SubMicroTrading ), but I’m convinced that idiomatic Rust would still be faster for the Fix parsing.

1 Like

An easier solution is just to be very specific about your memory requirements and only call GC after trading hours. This keeps your latencies consistent.

The catch is that everyone on the street is already doing that. You want to be faster than Java with no GC calls. And you can be with idiomatic Rust (whereas the Java involved to do the above is very unidiomatic Java). It is extremely impressive that Java's square peg can be put in the round hole, but there's much better ways to do things - Rust is perfect for this application.

1 Like

Here might be a good place to hang out:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.