Live data from Hacker News

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

news.efinancialcareers.com

191–200 of 483 posts

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

#191

Earlier quoted context omitted.

ehh I didn't even mention AWS - all I did was using the word 'instance' which seems to have thrown you off.

What else can "instance" mean, other than an instance of a virtual server? Granted may not be on AWS, but still is virtual which is a latency killer.

IMO you can't automatically go from "we have a latency requirement" to "public cloud is out of the question". It depends on what latency requirement. If you can eat an intermittent delay of 20ms, AWS, to me still seems fine, you just need to plan ahead in terms of what resources you rent there. Between that, and the multiple seconds a GC pause could cost you, there is still a space where GC optimization on AWS would make sense. But if you're in HFT and target micro- or even nanosecond optimizations, you sure don't wanna run anything in that critical path on any public cloud.

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

#192

Earlier quoted context omitted.

Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…

Why not just write it in C? And pre-allocate all the data structures, make them global, put them into a queue, and constantly reuse them. No more need to instantiate objects.

I write C++ for now almost 30 years, and always for the workloads where the cost of allocations was plainly visible, especially in the critical parts of the applications. So I have never stopped writing "non idiomatic" C++, at least from the point of view of typical language lawyers (and C++ attracted them a lot through the years). And I'm surely not the only one: there were different environments where it was recognized, through the times, first, that creating and destroying much objects was very bad, and later, with the growth of the C++ standard library, that even not everything in the C++ standard library should be treated the same, and that are better solutions than what's already available, and that the third party libraries are often bringing even more potential danger.

Depending on the goal, one has to be very careful when choosing what one uses. The good side is, C++ kept its C features: if I'm deciding how I'll do something, I don't have to follow the rules of the "language lawyers." I can do my work producing what is measurably efficient. And compiler can still help me avoiding some types of errors -- others can anyway be discovered only with testing (and additional tools). At the end, knowing good what one wants is the most important aspect of the whole endeavor.

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

#193

I’ve seen this sentiment before and worked on both a “low latency Java” team and low latency C++ teams. I have some sympathy for the idea that the JVM is better since it means you won’t spend all your time chasing crash reports. The thing is, like another comment hinted at, is that this issue is generally more reflective of the environment you build in than the technology choice. Here’s a good talk on the reasons for…

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.

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

#194

Seems like bending over backwards to use Java. If you are using Java in a c-like fashion, what's so bad with C++ which is c-like by default and has some Java-like features?

The article mentions crash logs. I can sorta relate, my company has their core application built in C (or C++? idk), and they will often have one FTE slave away for weeks analyzing a crash report / core dump, because apparently the code doesn't give nearly enough information to debug a production crash. whereas in Java you get an exception, a stack pointing neatly at where the issue was and an error that explains wha…

Fair enough, however I don't get how this ties up to "high speed trading systems". It can be said to be a general developer productivity advantage, not an advantage from technical perspective for this specific domain (which is what I thought the article was about and why I clicked the link)

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

#195

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.

Given the same conditions (i.e. people don't die) the same outcome would present itself. We have a history of bridges falling down, so much so that Wikipedia has a list on that: https://en.wikipedia.org/wiki/List_of_bridge_failures

A particular one that caught my eye: Cimarron River Rail Crossing Dover, Oklahoma Territory United States 18 September 1906 Wooden railroad trestle Washed out under pressure from debris during high water 4-100+ killed Entire span lost; rebuilt Bridge was to be temporary, but replacement was delayed for financial reasons.[8][9][10] Number of deaths is uncertain; estimates range from 4 to over 100.[11]

Emphasis mine. How is that different from software engineering?

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

#196
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.

I switched to C++ after years of doing web development in python, javascript and typescript, go and other high level languages associated with web dev. You're not wrong, the ego among C++ devs is astronomical. There's a huge amount of serious hate for python and this idea that being a C++ dev is superior. Get this we use Nix and C++ and the nix part of the code base is just as complex as the C++ code base. The nix st…

It's strange, I think that python and C++ are great languages to complement one another. You can write your critical stuff in C++ and use python to glue it all together, and it'll be a pretty effective solution (especially with the sheer amount of options in the python library ecosystem).

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

#198

Earlier quoted context omitted.

^^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.

Given the same conditions (i.e. people don't die) the same outcome would present itself. We have a history of bridges falling down, so much so that Wikipedia has a list on that: https://en.wikipedia.org/wiki/List_of_bridge_failures A particular one that caught my eye: Cimarron River Rail Crossing Dover, Oklahoma Territory United States 18 September 1906 Wooden railroad trestle Washed out under pressure from debris du…

The sarcastic/negative implication of your example is that software engineering today is where civil engineering was 100+ years ago.

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

#199

Has anyone used Golang for high speed trading? It seems like it hits all the sweet spots, yet it doesn't seem to be used that way. Does anyone know why?

I remember first seeing Go and taking a look at some of the interesting libraries it shipped with and thinking “this is a systems language” but it appears it mostly got relegated to web backend work.

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

#200
post #65

Earlier quoted context omitted.

In what regard do you think it's not mature enough yet?

The thing about Rust is that so many features are considered unstable and require switching to the nightly toolchain. That's just not suitable for real-world production use - yes, stuff does get stabilized eventually, but it takes time to really nail down the best possible design. Still, it's way better than the huge mess that is C++.

Which features are still holding you on nightly?
Post reply on HN