[lucozade]

> The surprising thing here is that it is considered worth it with those limitations.

It shouldn't be that surprising. Languages like Java and C# are perfectly sensible languages for writing the vast majority of a lot of trading systems. So it's eminently reasonable to use them, or equivalent, and deal with the bits that are GC-phobic as special cases.

I've worked with/on trading systems written is mainstream languages including C++, Java, C# and Python, as well as less mainstream such as APL and Smalltalk. I can safely say that there are way more critical concerns than whether or not it uses a GC.

[bitwize]

We have Rust now, and some safe memory usage patterns for C++. GC just increases your energy bill and helps heat up the planet.

[jhgb]

> GC just increases your energy bill

How? GC does its work in large batches once in a while, whereas for example Arc (the only serious alternative to what GC brings, which is the ability to have arbitrary graphs of objects) does its work much more frequently, with additional effort expended on atomic operations in a multithreaded environment, and with additional memory writes to boot. Somehow I doubt that GC "just increases your energy bill".

[rwmj]

[Citation needed] Rust encourages reference counting, a particularly inefficient form of GC which actually turns reads into writes(!), and it cannot move objects to compact memory except when it can prove that every object has only a single reference.

[tester756]

>We have Rust now, and some safe memory usage patterns for C++.

>GC just increases your energy bill and helps heat up the planet.

Were C++ compilation times that use 100% of my PC taken into consideration?

And not just for final binary, but also the compilations that happen everyday for development purpose too