I was a Java true believer in the late 90s/early 2000s, working on LimeWire, the most popular Java desktop app at the time (maybe of all time?). I thought we were close to a time when garbage collection was just as fast as manual memory management, and runtime re-optimization could make up for the extra time an ahead-of-time compiler could spend on optimizations. (Yes, I've read all of the Garbage Collection Handbook, and am aware of the speed advantages of bump allocation and the advantages of memory compaction. However, when it really matters, people still sidestep Java's GC using object pools and/or size their heaps such that they never collect while the stock market is open.)
Then, I started slinging C++ for the Google indexing system.
I still hope we get to a point where compiling to native code is as rare as hand-writing assembler is today. I hope we distribute code primarily in a format optimized for native translation, SafeTSA or similar. (Though, I'd hope we get install-time caching of native code generation, similar to AS/400 TIMI / current Android Runtime.)
However, until compilers get very good at statically inferring lifetimes and statically scheduling object collection, I hope garbage collection is optional and freely mixable with manually managed objects. (Yes, statically determining minimal lifetimes in the general case is equivalent to solving the halting problem, but we can be conservative and fall back on GC in the statically-unsolvable cases.)
The main drawback of Java for most applications is that with garbage collection there's a time-space tradeoff. As a rule of thumb in order to avoid frequent major collections, a Java program is going to use about twice as much memory as an equivalent C/C++ program.
When it really counts, we're still not at the point where Java is faster (even after warm-up) than expert-written hand-optimized C/C++ with profile-guided optimization.
Don't get me wrong. I understand the development velocity advantages of Java over C/C++ can often more than make up for performance differences, and good C/C++ developers (especially with domain-specific skills) are rather expensive to employ. I worked on equity trading systems in an interpreted language, where we replaced a lower latency system written in Java. The high-level interpreted language enabled a very rapid turnaround time and was easier for Statistics/Physics PhDs to implement models. The better models resulted in better average prices despite the system reacting more slowly to incoming data.
Ideally, I'd like to see something Elixir-like with good interoperability with something Rust-like for the parts that use a lot of CPU time and/or a lot of memory, all compiling down to a SafeTSA-like compressed control flow graph representation designed for fast native code generation.
Then, I started slinging C++ for the Google indexing system.
I still hope we get to a point where compiling to native code is as rare as hand-writing assembler is today. I hope we distribute code primarily in a format optimized for native translation, SafeTSA or similar. (Though, I'd hope we get install-time caching of native code generation, similar to AS/400 TIMI / current Android Runtime.)
However, until compilers get very good at statically inferring lifetimes and statically scheduling object collection, I hope garbage collection is optional and freely mixable with manually managed objects. (Yes, statically determining minimal lifetimes in the general case is equivalent to solving the halting problem, but we can be conservative and fall back on GC in the statically-unsolvable cases.)
The main drawback of Java for most applications is that with garbage collection there's a time-space tradeoff. As a rule of thumb in order to avoid frequent major collections, a Java program is going to use about twice as much memory as an equivalent C/C++ program.
When it really counts, we're still not at the point where Java is faster (even after warm-up) than expert-written hand-optimized C/C++ with profile-guided optimization.
Don't get me wrong. I understand the development velocity advantages of Java over C/C++ can often more than make up for performance differences, and good C/C++ developers (especially with domain-specific skills) are rather expensive to employ. I worked on equity trading systems in an interpreted language, where we replaced a lower latency system written in Java. The high-level interpreted language enabled a very rapid turnaround time and was easier for Statistics/Physics PhDs to implement models. The better models resulted in better average prices despite the system reacting more slowly to incoming data.
Ideally, I'd like to see something Elixir-like with good interoperability with something Rust-like for the parts that use a lot of CPU time and/or a lot of memory, all compiling down to a SafeTSA-like compressed control flow graph representation designed for fast native code generation.