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

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

news.efinancialcareers.com

Post reply on HN
Print view View original

251–260 of 483 posts

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

#251

Post by vmception »

vgatherps wrote: post #25

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…

VHDL is faster no?

Isn’t everything you wrote from the wrong decade?

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

#252

Post by Enginerrrd »

levosmetalo wrote: post #228
Karellen wrote: post #193

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.

"I need that bridge yesterday. If my army doesn't cross the river today, we are all dead. I don't care if the bridge collapse tomorrow, or if the rain wear it down, as long as I can use it today." If it's your job to do what is requested from you, then you do it. It's not like having brittle unmaintainable code is morally wrong. It's not engineers responsibility to judge use case of the customer paying for the bridge…

>It's not engineers responsibility to judge use case of the customer paying for the bridge.

Actually yes, yes it is! I am a civil engineer and there's a standard of ethics and personal responsibility among engineers that is very, very high. When we graduate, most engineers participate in a ring ceremony. They get a funny, angled ring on their right pinky. It was originally made from the metal from a bridge that fell down and killed people. It was meant to be a daily reminder, worn on the drafting hand, that every single drawing you signed carried the weight of public trust of their lives. Even pedestrian bridges get built with vehicle load standards, because you can't just assume that it will only be used by pedestrians.

Civil engineering is a licensure, and no matter what liability structure you use, when you stamp a drawing, you carry PERSONAL liability for anything that might happen if that design fails. Even small violations of ethics or operating outside your scope of knowledge are dealt with very aggressively by the licensing board.

In school, if we misplaced a decimal or got a calculation wrong or failed to adhere to a very specific standard, it was automatic failure because if you do that in real life, people die.

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

#254

Post by ryl00 »

beagle3 wrote: post #145
z92 wrote: post #5

When you write Java in a C like syntax : "Chronicle's system is built in what Lawrey describes as "C-like Java" and it's this that he encourages people to code low latency systems in." I guess very limited number of constructors, and most of all the methods are static. And they still struggle to find programmers that can code that way.

> When you write Java in a C like syntax And C is faster still when you write it with Fortran like (column order, and "restrict" mostly) semantics. An old mentor said to me 30 years ago that "A good programmer writes FORTRAN no matter what language they are using" (he was referring to speed of execution in the context of "good"). It seemed super funny at the time, but there's a lot of truth in that.

Why does column order matter? If you translate to the equivalent C/C++ row-major order, it should be laid out in memory the same way.

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

#256

Post by aldanor »

95th wrote: post #230
vgatherps wrote: post #25

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…

Well there is a middle ground - Rust

From what perspective exactly is Rust a middle ground Java and C++?

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

#257

Post by elros »

cobbzilla wrote: post #198
zanellato19 wrote: post #195

Earlier quoted context omitted.

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.

Given software engineering is less than 200 years old while civil engineering is a few thousand years old, I don't see this as a negative at all.

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

#258

Post by whbrown »

the_only_law wrote: post #199
varispeed wrote: post #197

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.

Web backend work at scale is all about building and maintaining distributed systems. Just consider the company where Go was designed ... And indeed, it's still a language of choice for teaching systems design[1].

[1] MIT 6.824: Distributed Systems - https://www.youtube.com/watch?v=cQP8WApzIQQ&list=PLrw6a1wE39...

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

#259

Post by vips7L »

DrBazza wrote: post #183
cies wrote: post #118

Earlier quoted context omitted.

Does anyone know of Rust in HTF teams? I think Haskell and OCaml may also be a good fit (and I know for a fact those are used in HFT teams).

From job ads I saw a year ago, there's at least one company in London doing HFT Rust. Also, if memory serves, one of Lawrey's ex-colleagues has written his own version of Chronicle in D that's being used somewhere too.

D seems like it would be a great choice for HFT. You get the productivity of GC when you want it and then you can have @nogc for critical sections of your code base.

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

#260

Post by travisporter »

Karellen wrote: post #193
angry_octet wrote: post #75

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.

I think software developers have a range in terms of responsibility from plumbers/electricians to civil engineers. We could save the designation “software engineer” for someone who has to go through the requisite ethics and case study courses like all other engineers. Otherwise maybe programmer/developer. (I’m gatekeeping I guess)
Post reply on HN