There are very few optimizations that a JIT can improve over a static compilation of a strongly-typed language. Strong typing brings immense capability for static analysis and subsequent optimizations. The most successful JIT optimizations out there typically are ones that make dynamic languages about as fast as statically typed languages by making assumptions about the runtime types of objects, while trapping/reoptimizing when those assumptions don't hold true. It also does pretty well finding hot loops and selectively optimizing those, but PGO gives you that too without any performance hit in your final executable.
A strongly typed language like Scala has the potential for massive optimizations under the whole program optimization umbrella...and no JIT would ever dare to try those types of optimizations, because they are extremely memory and compute intensive. They'd have to pause execution for minutes at a time just to figure out what to do.
I think it is unfortunate that Scala was designed for the JVM first. It brought a lot of syntactic baggage for interop purposes, and it saddled it with weird things like reflection and dynamic class loading, making it hard to statically compile. The ideas behind scala's type system are extremely powerful and could have fundamentally changed programming for the better, but all we got was a JVM me-too that was quickly usurped by Kotlin. I don't think it is dead or a lost cause...but the legacy that the JVM has on Scala is one that slowed it down, not sped it up (like what was claimed would happen with JVM languages).
It’s not as black and white. What about GC, compacting objects and the other myriad of optimizations the JVM does?
I do want to mention that I am not overly knowledgeable on these topics, only really interested in compiler technology, but a program compiled with PGO will have to add code for each specialized function, won’t it? So perhaps not every sort of application would win by PGO AOT compilation; a structure over the running code, and manipulations over it are a great and powerful idea.
But I do agree that Scala in the early years did have some ugly artifacts from compiling to the JVM and trying to remain a “good citizen“ there, not sure about current trends.
I agree that a AOT scala would be great. But don't JITs have the ability to react to real world usage and do hotspot optimization and stuff. I assume they are very complicated to build, and if you do thing ahead of time you should, but aren't the things that can only be done in a JIT important?
A strongly typed language like Scala has the potential for massive optimizations under the whole program optimization umbrella...and no JIT would ever dare to try those types of optimizations, because they are extremely memory and compute intensive. They'd have to pause execution for minutes at a time just to figure out what to do.
I think it is unfortunate that Scala was designed for the JVM first. It brought a lot of syntactic baggage for interop purposes, and it saddled it with weird things like reflection and dynamic class loading, making it hard to statically compile. The ideas behind scala's type system are extremely powerful and could have fundamentally changed programming for the better, but all we got was a JVM me-too that was quickly usurped by Kotlin. I don't think it is dead or a lost cause...but the legacy that the JVM has on Scala is one that slowed it down, not sped it up (like what was claimed would happen with JVM languages).