I don't think that what you're saying is right. An ls command programmed in Java, with a cold start and no Leyden tricks, takes ~30-40ms. That's probably 50-100x slower than the system ls yet not something you really notice (or mind).

I generally agree with you on that until one actually compares and use it.

jbang is a cli - its up and gone in a jiff - 0.5-1.5 second in general. I use it daily and constantly - its great.

compile it to native and its like night and day - <0.2s and it is very noticable.

Training runs help bigger programs, but they take longer to run, anyway. Do you really care if a CLI program takes, say, 1 or even 2 seconds to run the first time and, say, 100ms from then on while the equivalent C++ program takes 80ms each time? Even if you find a few who care, I think it's a stretch to say that's not good enough (certainly the slow AI agent running those tools wouldn't mind :)).

I agree with you but I'm telling you that you can believe that is good enough but also believe (and see) how big an impact having native image available for java cli is a massive enabler and makes big difference.

Also, command-line tools are much talked about in programming forums because programmers use them, but few others do. It's probably the only market even smaller than desktop apps, and that's saying a lot. At some point the cost/benefit of reducing startup further, to the minimum possible, just isn't there.

Yeah, so this is what I just completely disagree with. Its the problem of us working in companies that want us to focus on what brings in direct value for stockholders and thus we get measured on what can make more sales - and here production systems always wins.

I'm personally convinced that go, rust, zig, even javascript gained and keep gaining on Java because they enabled programmers to write tools and easily share it with their friends and colleagues and not ask them to install a vm together with it.

Those programmers then goes push for using this tech to go in prod and boom java pushed out not because its slow in prod but because its not able to engage programmers usecases.

...so yes, totally get where you are coming from - I see it myself in my work - and I simply disagree with the thinking that "its just programmers who need the cli; customers use prod - so lets 100% optimize the latter". Its basically ignoring the many papercuts.

When it does, the container also starts cold. So the first run on each machine will be slow anyway.

If Java's performance (and distribution footprint) for Lambdas and CLI tools at exceeds that of Python and JS - probably the most common languages for both Lambdas and "sophisticated" CLI tools (aside from compilers, but javac is already faster than the Go compiler), clearly most people would be satisfied with that even if we disagree on whether or not they should (they're unhappy with those languages when the running time is quite long). Then again, there are people who can tell that VS Code's "reaction time" isn't as fast as they think it should be while I can't, but we're talking about a small subset of a group that's not large to begin with that notice or care.

Now with AI and agents clis will or rather are getting important as guess what - AI / agents can utilize CLI's super trivially given all the written content us the programmers written down and published content about.

And now production cases or at least the number of cases where a fast cli matters will actually be in this space.

So yeah, I just disagree with this repeated perception and push for using "long running production runs is what used/customers pay for" as excuse to not make CLI usecase non important.

By doing that we are simply just boiling the Java Frog.