4 ms·

Language with a fast runtime minus startup (although maybe they've fixed the startup since I last looked) that is incredibly tunable to fit your specific needs

Language with a fast runtime minus startup (although maybe they've fixed the startup since I last looked) that is incredibly tunable to fit your specific needs for good performance profile, while not needing to manage raw memory the way c or c++ would. Personally I prefer c#, but a lot of places already were using Java in significant ways before c# became good (IMO 2.0ish) and saw no reason to change.

kaba0 5y ago
Java’s startup only slows down when a ton of classes have to be loaded, e.g. that’s why Clojure’s repl takes quite some time as you are loading two standard libs. For a simple hello world it is below 0.1s.
- pkolaczk 5y ago
  But noone cares about hello world. You're not building hello-worlds in real life. Slow startup time is a problem in automated testing of big codebases - when you aim to test the whole codebase, but each test alone does not stress any code path hard enough for the hotspot compiler to kick in. So basically most of your Java code in testing runs in interpreted mode, which is like 20x-100x slower than properly compiled and optimized C/C++/Rust.
  - kaba0 5y ago
    That’s just not how it works. If no code path gets run enough times, then frankly, it simply doesn’t matter, they could have been written in bash and still be “fast enough”. Like, I can’t fathom a program that doesn’t have loops where the actually important part happens. You simply can’t write enough “linear” code to make a modern CPU sweat even just a little. And if you do have said loop, than it will be JIT compiled.
    - pkolaczk 5y ago
      But it's not just interpreting linear code. It is also classloading which involves a non-trivial amount of work before any code in a class can even run. Also I never said the testing code doesn't have any loops. There often are loops but they need to run for a really long time until hotspot kicks in. So if you lose a few tens of millisecond here and there in a single test, you will get minutes or hours in total in a codebase that has hundreds of thousands tests. And it gets terribly worse if many of your tests are end-to-end tests that e.g. launch new JVMs.

kaba0 5y ago

Java’s startup only slows down when a ton of classes have to be loaded, e.g. that’s why Clojure’s repl takes quite some time as you are loading two standard libs. For a simple hello world it is below 0.1s.

pkolaczk 5y ago
But noone cares about hello world. You're not building hello-worlds in real life. Slow startup time is a problem in automated testing of big codebases - when you aim to test the whole codebase, but each test alone does not stress any code path hard enough for the hotspot compiler to kick in. So basically most of your Java code in testing runs in interpreted mode, which is like 20x-100x slower than properly compiled and optimized C/C++/Rust.
- kaba0 5y ago
  That’s just not how it works. If no code path gets run enough times, then frankly, it simply doesn’t matter, they could have been written in bash and still be “fast enough”. Like, I can’t fathom a program that doesn’t have loops where the actually important part happens. You simply can’t write enough “linear” code to make a modern CPU sweat even just a little. And if you do have said loop, than it will be JIT compiled.
  - pkolaczk 5y ago
    But it's not just interpreting linear code. It is also classloading which involves a non-trivial amount of work before any code in a class can even run. Also I never said the testing code doesn't have any loops. There often are loops but they need to run for a really long time until hotspot kicks in. So if you lose a few tens of millisecond here and there in a single test, you will get minutes or hours in total in a codebase that has hundreds of thousands tests. And it gets terribly worse if many of your tests are end-to-end tests that e.g. launch new JVMs.