I've been saying the same thing: We need an ahead-of-time compiled high level, business language. Something as efficient as Rust, but not designed for embedded microcontrollers or systems software.
I feel like the entire industry has had a "kneejerk reaction" to C++ and its abysmally slow compile times. Everyone jumped onto the interpreter bandwagon and ended up throwing the baby out with the bathwater.
It is definitely possible to have sub-second compile times for large, complex software! Just look at Jonathan Blow's Jai language. He can recompile and reload an entire 3D game engine in about that time.
We can have our cake and eat it to. We can have efficient, compiled languages and still have safety and fast compilation.
I can only think of Ruby and Python that use a strictly interpreter mode (in their most common runtime).
Java, C# use a hybrid solution, but for all practical purposes they are running as extremely efficient machine code, how is it not “efficient business language”?
They're both JIT compiled, not ahead-of-time compiled. This severely limits the type of optimisations that they can perform, because they have to do it "on the fly" during runtime.
Being pedantic, both have AOT compilers readily available.
But sure, though I don’t really buy the argument that JIT compilers would “severely limit” the type of optimizations - there is no significant performance difference - if any - between AOT compiled managed languages and JIT-compiled ones. Sure, there are more constraints in case of a JIT, but it’s not like going in the other direction and letting gcc/clang chew 10x time more on the same program would give you a significant speedup, if any. Speculations (which are not possible AOT) may even reverse the fields.
D, Haskell, OCaml, Go are all in the same ballpark as Java and C#, and even JS, hell, they may be better.
The AOT compiled managed languages are hamstrung in no small part by their fundamental design, which was intended for virtual machines. Java and C# were designed in the 1990s. Since then, hardware has changed. For example, indirect calls are much more expensive in relative terms, and the memory bloat introduced by template metaprogramming is much less of a limitation.
Imagine a language as easy to use as Python, with the strong typing of Typescript, but designed from the ground up to always be fully compiled and hence running as fast as C++, but with build times measured in fractions of a second... fast enough to feel interpreted.
The biggest speedup one could get on modern hardware (in single-threaded context) comes from effectively using the CPU caches and in certain cases, vectorization. Clever use of these can give you 10-100x speedups.
This extra optimization is somewhat offset by the very point of a managed language: the programmer don’t want memory layout details to leak into the design/APIs, but in the rare case it is needed it can be done just as well with the escape hatches they provide (byte buffers, value types also bring you quite far). But business logic seldom involve these scorching hot loops to begin with, so there may not even be anything to optimize in this manner.
I feel like the entire industry has had a "kneejerk reaction" to C++ and its abysmally slow compile times. Everyone jumped onto the interpreter bandwagon and ended up throwing the baby out with the bathwater.
It is definitely possible to have sub-second compile times for large, complex software! Just look at Jonathan Blow's Jai language. He can recompile and reload an entire 3D game engine in about that time.
We can have our cake and eat it to. We can have efficient, compiled languages and still have safety and fast compilation.