Live data from Hacker News

Java is better than C++ for high speed trading systems

news.efinancialcareers.com

281–290 of 483 posts

Re: Java is better than C++ for high speed trading systems

#281

Earlier quoted context omitted.

> software engineering hasn't killed enough people to advance and where it had, you get pretty serious control and certification process put in place to avoid it (Boeing notwithstanding)

The 737 Max issues were not with the software.

There seems to be plenty of software issues found:

The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down. The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed.

While reviewing the software systems, a number of other software issues were found.

The wiring bundle issue was also found during these reviews.

https://www.barrons.com/articles/these-6-issues-are-preventi...

https://simpleflying.com/boeing-737-max-software-update-3/

Re: Java is better than C++ for high speed trading systems

#282

Hearing them describe this "C-like Java", I'm surprised C# wasn't a better fit given that it has value-type "structs" that don't have to sit behind a reference on the heap. As far as I know, Java still doesn't have an equivalent feature. Maybe the JVM's GC is just so much faster that it's worth it?

Java got popular for HFT before .NET core. c# was just generally slower at the time. It would likely be the preferred choice at this point. Though Rust is really perfect for this kind of thing.

I'm surprised I haven't heard anything about rust in this area. It seems like it could do well what hft people want without the problems of c++. Though I don't know rust, so I'm not sure how well you can force the correct optimizations.

Re: Java is better than C++ for high speed trading systems

#283

As an HFT programmer I like this article because it means less competition for me. I mean, you can write a very fast system in Java but by the time you accomplish that goal you’ll have spent as much or more time than if you had just used C++.

As an HFT developer myself I have to disagree. I worked for tier 1 banks that used both:java and cpp. The trend is moving towards quicker time to market and simpler implementations and replacing cpp with java. The cpp code bases I had to deal with were old, hard to maintain and easy to break. More often than not cpp was a pretty bad lock in as well. For example a big evil bank very well known here struggled for 3 yea…

How is replacing with Java better than replacing with C++? Legacy code is a problem, and bad programmers will write bad code in any language. If you need to start over does Java give you anything you can't get with modern C++?

Re: Java is better than C++ for high speed trading systems

#284
post #61

C++ is a fantastic language but it somehow attracts people with big ego. The smartest people I know would always try to simplify things, but many C++ developers (especially in financial industry) have this preference for complexity I can't explain. And C++ is the worst language to get clever with.

C++ lets you "get things done" when the other tooling you need is your brain. Unfortunately, that might mean template metaprogramming that makes a compile take >50 minutes, and where any syntax error typo generates a 4000-line error message -- but for some people, being to use C++ to get things done is an intellectual reward onto itself. If you wanted to get the same performance from C, you'd sometimes need to write…

well, at least there's also constexpr now which reduces some amount of need for template metaprogramming

Re: Java is better than C++ for high speed trading systems

#285
post #10
post #3

This is not "why Java is better for fast things". It is not. This is "why Java is better", and the answer is "it usually is better because your programmers often suck".

If programmers didn't suck, we would do everything in ASM. Since programmers are humans, we need abstractions like C or C++. Java, C#, Python, Go, Objecttive-C, and other garbage collected languages are there to make programming easier.

These days the optimizer is so good few humans can do better over a large program. Even if they can, Intel will release a new cpu, or someone will buy amd and all your asm code is lost while those who write a compiled language just change a flag and get completely different binary.

Re: Java is better than C++ for high speed trading systems

#287

I used to work on a high-speed messaging system built in Java, and garbage collection was a killer. No matter how much we tweaked the code and the GC parameters, and this eventually got escalated pretty high up in Sun itself, we'd get these occasional multi- minute pauses where the whole thing would just freeze up, buffers would fill and stuff would start dropping on the floor. This was over 10 years ago, so things m…

Cassandra has some of these issues as well, despite arena allocation, buffer reuse, and offheap manually allocated memory.

10 years has seen improvements to GC, but not eliminated the problem.

Cass 4.0 finally enables ZGC, so we'll see how that goes.

If you have stateless, you could do two JVMs and monitor the GC state, and reroute requests to a low-heap JVM and let the other clean up.

Garbage collection is hard.

I'm surprised that there aren't expert-level concepts like weak references and ways to sub-partition the heap, with say a new operator that can target a partition, so major GC doesn't have to do the whole heap. Although that starts getting into rust concepts and analysis.

Re: Java is better than C++ for high speed trading systems

#288

Ex-Wall Street guy here. High speed trading has no societal value and relies on a large number of bad-faith bids and offers - these people are parasites. Creating liquidity has some value - though not as much as bankers tell themselves. But HFT does not add liquidity. No one needs subsecond liquidity, but even more important, HFT traders vanish like a fart in a windstorm the moment liquidity is actually challenged. M…

> High speed trading has no societal value

And investment banking does?

>Even just charging a dollar for every "bad faith" bid or offer made that expires without being within, say, 10% of the actual price, would put a big dent in them.

Tell me this, what is the actual harm of these orders?

Re: Java is better than C++ for high speed trading systems

#289

Earlier quoted context omitted.

The worst (messiest, laziest and most chaotic) engineer I know works at a brokerage, coding obscenely large and unreliable edifices (and in a number of languages, from C++ to Excel+VB)... He does what he is asked, and doesn't worry about telling them what they need. They never demand code that doesn't crash, they see that as a fact of life, and developers are an overhead. Basically someone else owns the risk, the bro…

^^This^^ is why you shouldn't call software developers "engineers" (disclaimer, am software developer). "No-one ever explicitly specified that the bridge shouldn't fall down and kill everyone who was on it at the time", said no engineer, ever.

The state of software engineering these days resemble that of civil engineering of late 19th century: some masterpieces, some failures and lots of experiments.

Do we put the cockpit in front of the boiler or behind?

Do we make a walking steam engine? How about using gears instead of wheels?

Which gauge to pick for the rails?

We'll get there in software engineering at well. It will be very reliable and equally boring.

Re: Java is better than C++ for high speed trading systems

#290
I had a sign hanging from a column in one of my previous offices. It read "You must be this tall to use threads and shared mutable state -->". It was about 3 meters from the floor.

It's a bit harder to write some bugs in Java than it is in C or C++. I gather it'd be almost impossible to write them in Rust.

Post reply on HN