3 ms·

I'm surprised this article doesn't talk about the common issue with writing a trading bot in Java, which is the floating point types. I worked on a trading bot

I'm surprised this article doesn't talk about the common issue with writing a trading bot in Java, which is the floating point types. I worked on a trading bot in Java over a decade ago when it was common in the industry to do so. We wrote a fixed precision decimal library which was about 4x faster than the alternative BigDecimal type. It worked out quite well, but Java doesn't allow operator overloading, so the whole code base looked like a mess with tons of a.mul(b.add(c)) looking lines of code. When C++14 came out the project was ported to C++. It needed to go fast, but more importantly it needed to be stable and readable. An error in code could cost us, which wasn't something we could accept. Moving to modern C++ wasn't fun, but the code is clean, easy to read, works and works well. Today, the code base has started to be ported to Rust, but unlike going from Java to C++, this move isn't as big of a deal, but the added safety is appreciated given the nature of the project. Today it's pretty common for firms to create their own lisp like or Haskell like programming language. By having it FPP it can mirror mathematics a bit closer which reduces bugs, yet by having it in house it can be fast, otherwise these companies would use a common language. We are the only ones I know of moving towards Rust. I imagine a lot of firms who are aready C++ are going to stay with modern C++.

cogman10 6y ago
Does rust buy much for HFT? I mean, if you leak memory or have a use after free issue, it's not the end of the world since this isn't exposed to untrusted input. Though, I'm sure the language features like async/await and safe concurrency are probably appreciated.
- proverbialbunny 6y ago
  From Java to C++ it was more about messing up the logic, because it was so difficult to read. This was a while ago, but there was a Perl script where you could write a kind of psuedo code and it would convert it into the Java syntax, so we could look at the math behind it in a clear way. >Does rust buy much for HFT? Going from C++ to Rust is low priority. It may not ever be finished. That low of a priority. It's more about refreshing the code base. One thing that surprised me is Rust can be faster than C++ at certain tasks. The big benefit is if you have a new dev coming on and they try to modify something that would introduce a bug, the compiler is all over it. Currently acceptance tests are all over it and work fine and C++ can be pretty strict so it works, but Rust is more ideal for this.

cogman10 6y ago

Does rust buy much for HFT? I mean, if you leak memory or have a use after free issue, it's not the end of the world since this isn't exposed to untrusted input. Though, I'm sure the language features like async/await and safe concurrency are probably appreciated.

proverbialbunny 6y ago
From Java to C++ it was more about messing up the logic, because it was so difficult to read. This was a while ago, but there was a Perl script where you could write a kind of psuedo code and it would convert it into the Java syntax, so we could look at the math behind it in a clear way. >Does rust buy much for HFT? Going from C++ to Rust is low priority. It may not ever be finished. That low of a priority. It's more about refreshing the code base. One thing that surprised me is Rust can be faster than C++ at certain tasks. The big benefit is if you have a new dev coming on and they try to modify something that would introduce a bug, the compiler is all over it. Currently acceptance tests are all over it and work fine and C++ can be pretty strict so it works, but Rust is more ideal for this.