News for hackers. Stuff that matters.
Re:We chose Java for our high-frequency trading application by tormeh on Monday October 26, 2020 @10:45AM (#24896686)
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..
Re:We chose Java for our high-frequency trading application by fractionalhare on Monday October 26, 2020 @11:13AM (#24897017)
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 to replace C++ for their use cases. If anything, Rust's dependency management story would be the thing to highlight (this is part of what's compelling about the JVM).

Re:We chose Java for our high-frequency trading application by jariel on Monday October 26, 2020 @11:25AM (#24897178)
"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 by fractionalhare on Monday October 26, 2020 @11:48AM (#24897452)
That's fair. Instead of saying "software security" I should have been more specific in talking about memory and pointer issues. In that sense, yes Rust does offer some safety guarantees beyond preventing memory corruption vulnerabilities.
Re:We chose Java for our high-frequency trading application by nv-vn on Monday October 26, 2020 @12:36PM (#24898040)
Jane Street famously uses OCaml for these types of guarantees, so I would think Rust would offer similar benefits.
Re:We chose Java for our high-frequency trading application by fractionalhare on Monday October 26, 2020 @12:44PM (#24898144)
Why would you think that? Rust's major selling point for safety guarantees is the borrow checker. It does not provide most of OCaml's type and functional semantics.

That being said: Jane Street is pretty avant garde in this respect. I expect there already is, or soon will be, a successful trading firm which likewise builds its tech brand on Rust and alternatives to Rust standard library primitives. But overall adoption will probably continue to be anemic.

Re:We chose Java for our high-frequency trading application by tormeh on Monday October 26, 2020 @12:53PM (#24898252)
It has immutability, no null pointers, and error types. It has escape hatches available for everything, but unnecessary use of these should be caught in code review, so I don't think it's a big deal. Not sure what correctness features OCaml could add beyond those, but then again I've never programmed in OCaml, only Scala, so I might be wrong.
Re:We chose Java for our high-frequency trading application by WJW on Monday October 26, 2020 @03:09PM (#24899952)
This is perhaps the most "blub" comment ever written. There are whole classes of bugs that can be caught with more advanced type systems that the Rust type system + borrow checker will never catch. No null pointers and immutability is the bare minimum.

If you're interested, check out https://www.youtube.com/watch?v=10gSoVZ5yXY for an example of the types of compile time guarantees can be had.

Re:We chose Java for our high-frequency trading application by tormeh on Monday October 26, 2020 @07:48PM (#24902940)
Does OCaml have dependent types? I thought that was a Coq and Idris (and Haskell, to a lesser extent) thing.

I am aware that dependent types exist, but quite frankly I've yet to see a popular/ergonomic language implement them. As much as we'd like absence of null pointers, error types, and immutability to be the norm it is not and it will take decades until it is.

Re:We chose Java for our high-frequency trading application by pjmlp on Tuesday October 27, 2020 @04:55AM (#24905565)
You can also do it in Ada/SPARK, Eiffel DBC, F*, Dafny.
Re:We chose Java for our high-frequency trading application by pjmlp on Monday October 26, 2020 @11:31AM (#24897245)
A language that brings the Gentoo installation experience to external libraries and requires special purpose data structures to compile properly?
Re:We chose Java for our high-frequency trading application by scaladev on Monday October 26, 2020 @11:35AM (#24897305)
Do you prefer the Linux from Scratch installation experience which C and C++ provide?
Re:We chose Java for our high-frequency trading application by pjmlp on Monday October 26, 2020 @12:42PM (#24898124)
Only for clueless developers that don't know their trade.
Re:We chose Java for our high-frequency trading application by troebr on Monday October 26, 2020 @11:18AM (#24897079)
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 by fractionalhare on Monday October 26, 2020 @12:28PM (#24897903)
If I said Rust is rarely used in trading I'd be still overstating its adoption. There is approximately no Rust code in buy side finance. It exists in the sense that you could find something written in it somewhere, even it it's just an infra tool used by one of the software engineers. But I would be very surprised to hear of any trading firm that uses it in the hot path.
Re:We chose Java for our high-frequency trading application by alexeiz on Friday October 30, 2020 @04:30PM (#24946586)
A language that should not be named.