Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We chose Java for our high-frequency trading application

medium.com

Post reply on HN
Print view View original

31–40 of 287 posts

Re: We chose Java for our high-frequency trading application

#31

Post by troebr »

tormeh wrote: post #13
troist wrote: post #2

I've used Java and C++ in a few low latency applications and I do prefer Java in certain scenarios. The whole ecosystem around Java makes rapid development easier meaning we could make safe changes quicker which is a big benefit in trading systems where you need to react to unpredictable market conditions. The article focuses quite heavily on Zing vs Hotspot but it'd be interesting to see an analysis of a variety of…

If you want something that's as fast as C++, but safer to work with, then there's this new language, has been on HN frontpage once or twice.. I can't remember the name, but I think it had something to do with oxidation of metals.. Something about shellfish as well..

I was surprised there was no mention of it in the article. Maybe it's not used commonly in the trading space?

Re: We chose Java for our high-frequency trading application

#32

Post by [deleted] »

tormeh wrote: post #13
troist wrote: post #2

I've used Java and C++ in a few low latency applications and I do prefer Java in certain scenarios. The whole ecosystem around Java makes rapid development easier meaning we could make safe changes quicker which is a big benefit in trading systems where you need to react to unpredictable market conditions. The article focuses quite heavily on Zing vs Hotspot but it'd be interesting to see an analysis of a variety of…

If you want something that's as fast as C++, but safer to work with, then there's this new language, has been on HN frontpage once or twice.. I can't remember the name, but I think it had something to do with oxidation of metals.. Something about shellfish as well..

[deleted]

Re: We chose Java for our high-frequency trading application

#35

Post by mumblemumble »

One bit of useful background knowledge: The technical demands for high frequency trading can vary wildly depending on both what kind of trading strategies you're using, and what market you're in. This translates into real-time needs that vary considerably, depending on context.

At one firm I used to work at, the spread was several orders of magnitude. On one end, people were counting nanoseconds, and even C++ wasn't fast or predictable enough. At the other extreme, some teams didn't care about anything finer than a millisecond, and a big chunk of the stack was written in managed languages. It all counted as high frequency trading.

Re: We chose Java for our high-frequency trading application

#36

Post by [deleted] »

taion wrote: post #12
cashewchoo wrote: post #5

I think I actually saw these folks present at JavaOne a couple years ago? Either that or there's more than one shop branding itself as "HFT" that uses Java. I worked in the industry and it's always a little funny to see who calls themselves HFTs vs quants. Basically, there's a bit of a spectrum of fast vs smart. In general it's hard to do incredibly smart stuff fast enough to compete in the "speed-critical" bucket of…

There are still a number of players in the HFT space that use JVM languages. I think as with any space, if you really zoom into the details, you see a lot of diversity. You're obviously right in that people who are still hitting the CPU can't compete with people that do everything on FPGA, but it seems like there's still plenty of money to be made by people who are just a bit less fast than that. I've heard people ar…

[deleted]

Re: We chose Java for our high-frequency trading application

#37

Post by kyawzazaw »

taion wrote: post #12
cashewchoo wrote: post #5

I think I actually saw these folks present at JavaOne a couple years ago? Either that or there's more than one shop branding itself as "HFT" that uses Java. I worked in the industry and it's always a little funny to see who calls themselves HFTs vs quants. Basically, there's a bit of a spectrum of fast vs smart. In general it's hard to do incredibly smart stuff fast enough to compete in the "speed-critical" bucket of…

There are still a number of players in the HFT space that use JVM languages. I think as with any space, if you really zoom into the details, you see a lot of diversity. You're obviously right in that people who are still hitting the CPU can't compete with people that do everything on FPGA, but it seems like there's still plenty of money to be made by people who are just a bit less fast than that. I've heard people ar…

In a info session, IMC mentioned they use Java for some of their systems.

Re: We chose Java for our high-frequency trading application

#38

Post by stzup7 »

jariel wrote: post #30
posnet wrote: post #16

Except that HFT firms don't call themselves HFT any more, they re-branded to ultra-low latency trading. And FPGAs are the norm now, not the exception. Sure, Java still has its place, but implying that it is anywhere in the hot loop of a contemporary ULL system is wrong at best and disingenuous at worst. I mean just read the abstracts from this years STAC conference. https://www.stacresearch.com/spring2020

It's an entire industry devoted to wasting enormous energy, resources and intellectual capacity. There are simply no material external gains from HFT etc, it's completely zero-sum other than maybe a 'job creation program'. The site ridiculously talks about 'levelling the playing field' by extending HFT opportunities to other players, which is rich, considering the playing field could be 'levelled immediately' by some…

I don't think that's quite right. It's the same way Formula 1 racing contributes to regular automotive industry. Technological innovations could be adopted by more mainstream industries in a few years. For instance SolarFlare NICs used to be almost exclusively used by HFT players and can now be found in most CDNs or latency sensitive cloud providers.

Re: We chose Java for our high-frequency trading application

#39

Post by jariel »

fractionalhare wrote: post #28
tormeh wrote: post #13

Earlier quoted context omitted.

If you want something that's as fast as C++, but safer to work with, then there's this new language, has been on HN frontpage once or twice.. I can't remember the name, but I think it had something to do with oxidation of metals.. Something about shellfish as well..

The person you're replying to is almost certainly not using the word "safe" in the same sense you are. In particular: safety in trading has to do with risk management, strategy correlation, side effects, and correctness. Software security matters, in the abstract, but trading firms don't care about it nearly as much as tech companies do. The other thing is that being as fast as C++ is not compelling enough a reason t…

"Software security matters"

I think the responder's version of 'safety' really boils down to 'null pointer safety' - not 'software security'.

And even then, people keep talking about it like it's 'the thing'.

Java has null 'references' as do most languages frankly and it's just 'a thing' almost never 'the thing' to be concerned about.

'What devs want' is basically something kind of like Java, but that compiles, predictable/controllable performance and memory management i.e. no GC. That's it. It will probably end up being Rust, but that's because Rust will eventually provide all the nice, clean, modern package management, idioms, libraries etc., not specifically because of the 'safety'.

Granted I don't want to diminish that in the attempt to create 'proper memory management' you probably end up writing better software anyhow.

Re: We chose Java for our high-frequency trading application

#40

Post by stzup7 »

dangerbird2 wrote: post #8

Does anyone know if C#/dotnet is used in HFT to any extent? I'd imagine proper support for user-defined unboxed types (structs) and non-hacky methods for manual memory management (unsafe) could give it major advantage over Java with much of the QoL improvements java has over C++.

I've seen it on the client-side. HFT software, written in C or C++ is piloted by traders with C# / .NET apps via RPC
Post reply on HN