4 ms·

Not sure what startup time matters for running a persistent service is, and it's obviously tied to hardware. You can get applications up and running in less tha

Not sure what startup time matters for running a persistent service is, and it's obviously tied to hardware. You can get applications up and running in less than second or so (we were using Micronaut to resolve dependencies at compile time). If you use GraalVM you can compile to native code and now we're talking a few tens of milliseconds to get an application up and running (or execute and exit).

pohl 3y ago
That was always the story back then, too — the assumption that no one writes anything other than services with long uptimes. No CLI tools, no lambdas, no quick-launching GUIs. Sounds like that bias hasn't really changed over the years?
- kaba0 3y ago
  You pay for what you use. If you bring in a litany of libraries to connect to some endpoint in every conceivable IPC mechanism then sure, it will take some time (but let’s not forget that it would also take considerable time with native machine code). But besides very very frequently run CLI tools like ls, the problem is entirely overblown. Come on, quick-launching GUIs? I hardly even remember that being a thing.
  - pohl 3y ago
    You pay for what you use. Exciting, if true. So, for example, could I choose to not use garbage collection or class loading or JIT compilation and avoid paying their costs?
    - kaba0 3y ago
      I was quite obviously talking about loading many classes. But.. yeah, you can disable the GC and also the JIT compiler, for whatever reason.
- jwr 3y ago
  Not sure if it's a "bias". The JVM does start up slowly. This has never been an issue for me in all the years I've been using Clojure. If I need "scripts" with short start-up times, I'll use Babashka (GraalVM) or ClojureScript (Node). Same language, instant start-up. But then I don't expect to get good performance from those VMs for long-running services with large memory allocations. Use the right tool for the job at hand?

pohl 3y ago

That was always the story back then, too — the assumption that no one writes anything other than services with long uptimes. No CLI tools, no lambdas, no quick-launching GUIs. Sounds like that bias hasn't really changed over the years?

kaba0 3y ago
You pay for what you use. If you bring in a litany of libraries to connect to some endpoint in every conceivable IPC mechanism then sure, it will take some time (but let’s not forget that it would also take considerable time with native machine code). But besides very very frequently run CLI tools like ls, the problem is entirely overblown. Come on, quick-launching GUIs? I hardly even remember that being a thing.
- pohl 3y ago
  You pay for what you use. Exciting, if true. So, for example, could I choose to not use garbage collection or class loading or JIT compilation and avoid paying their costs?
  - kaba0 3y ago
    I was quite obviously talking about loading many classes. But.. yeah, you can disable the GC and also the JIT compiler, for whatever reason.
jwr 3y ago
Not sure if it's a "bias". The JVM does start up slowly. This has never been an issue for me in all the years I've been using Clojure. If I need "scripts" with short start-up times, I'll use Babashka (GraalVM) or ClojureScript (Node). Same language, instant start-up. But then I don't expect to get good performance from those VMs for long-running services with large memory allocations. Use the right tool for the job at hand?