It's a non-issue with GraalVM native binaries. See https://news.ycombinator.com/item?id=46445989 for an example: this CLI tools starts in ms, fast enough you can launch it during tab completions and have it invoke a REST API without any noticeable delay whatsoever.
But also when running on the JVM, things have improved dramatically over the last few years, e.g. due to things such as AOT class loading and linking. For instance, a single node Kafka broker starts in ~300 ms.
graalvm is literally 500x more overhead than a statically linked dash script.
Maybe not an issue for terminal UIs, but the article mentions both TUIs and CLI tools. A lot of people use CLI tools with a shell. As soon as you do `for file in *.c; do tool "$file"; done` (as a simple example), pure overhead on the order of even 10s of ms becomes noticeable. This is not theoretical. I recently had this trouble with python3, but I didn't want to rewrite all my f-strings into python2. So, it does arise in practice. (At least in the practice of some.)
A hasty generalization with a little confirmation bias, perhaps?
$ time keenwrite.bin --version
KeenWrite version 3.6.5
Copyright 2016-2025 White Magic Software, Ltd.
user 0m0.329s
From Claude:
> It's worth noting this is a common perception about Java, and there's some historical truth to it (especially with Swing desktop applications from the 2000s). However, the absolute statement "no Java app... ever" is the fallacy - it's an overgeneralization from limited personal experience to a universal claim.
It's a non-issue with GraalVM native binaries. See https://news.ycombinator.com/item?id=46445989 for an example: this CLI tools starts in ms, fast enough you can launch it during tab completions and have it invoke a REST API without any noticeable delay whatsoever.
But also when running on the JVM, things have improved dramatically over the last few years, e.g. due to things such as AOT class loading and linking. For instance, a single node Kafka broker starts in ~300 ms.
Time comparisons are (or should be) relative. https://news.ycombinator.com/item?id=46447490
graalvm is literally 500x more overhead than a statically linked dash script.
Maybe not an issue for terminal UIs, but the article mentions both TUIs and CLI tools. A lot of people use CLI tools with a shell. As soon as you do `for file in *.c; do tool "$file"; done` (as a simple example), pure overhead on the order of even 10s of ms becomes noticeable. This is not theoretical. I recently had this trouble with python3, but I didn't want to rewrite all my f-strings into python2. So, it does arise in practice. (At least in the practice of some.)
> started in a reasonable amount of time
A hasty generalization with a little confirmation bias, perhaps?
From Claude:> It's worth noting this is a common perception about Java, and there's some historical truth to it (especially with Swing desktop applications from the 2000s). However, the absolute statement "no Java app... ever" is the fallacy - it's an overgeneralization from limited personal experience to a universal claim.
It’s not a generalisation. I am a specific individual relating my own experiences. I have no idea what your app is and have had zero reason to use it.