[simonh]

Interesting. I wouldn't have though Java was suitable for HFT due to garbage collection pauses playing havoc with your system determinism and performance reliability.

I supported a derivatives trading system written in java that was canned due to performance issues, and where I am now we had java FIX protocol gateways that we've replaced with C++ components, again for performance reasons.

I'm not saying java has performance problems in general, I do understand that for many applications it's a good and performant option, but when you're dealing with sub-millisecond response times it has issues. If anyone is using Java for applications like this, I'd love to know how they get round these issues.

[ironchef]

Nah...there's tons of workarounds these days which make things way faster / less latent. Couple quick examples:

* look at memory mapped data in java (basically using sun.misc.Unsafe lets you deal with things like malloc and free)

* look at increasing use of primitives and collections that utilize primitives appropriately

* properly profile / size your eden space

yada yada ... i think a lot of HN people have generally just wrote off java as not as fast as C, not as productive as python/ruby, and not as exciting as lisp, haskell, FOTM. Java's a fine tool like anything else...just need to use it appropriately.

[daigoba66]

Check out LMAX. They've built an exchange that runs on Java. Their engineers are constantly talking/blogging about getting Java to perform well. "Mechanical Sympathy" is the buzzword they've coined.

[liljimmytables]

> garbage collection pauses

AFAIK, mark-and-sweep GC was removed from the JVM years ago (except on Android, where Dalvik used it until 2.something). I can't help with the rest of your post though.

[VLM]

I'm surprised they'd do it all in one language. High level decisionmaking in a high level language, simple low level execution in a low level language.

[sc0rb]

Plenty of word class trading systems are running Java.