4 ms·

Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Ok

Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go. Python has many similar properties, but at least there I can understand that Python is a 'pretty' language to write things in. Java has never been something that I have ever wanted to choose, and far, far less so when there's a big hill to climb like this. I guess I fundamentally disagree with all the statements in the article like "This needs to change". I don't think it does. I would much rather than people wrote CLIs in Go or Rust than Java, 100% of the time the latter has been more painful for me to consume.

jazzyjackson 10mo ago
Its not necessarily fair to use past experience with programming languages that have been seeing major updates year over year. Java as a command line environment has been pretty painless for me, particularly Saxon. Just need to alias the command to include a path to the jre binary. Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.
unlikelytomato 10mo ago
Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years. The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by convention. I would love a rich java ecosystem of TUI/CLI libraries to reuse all of my existing business logic and company libraries. The lack of extremely streamlined wrappers is the only barrier. In my work environment, this would be a great addition.
- CamouflagedKiwi 10mo ago
  Right, as I said I also think Python has similar issues with startup time. I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.

jazzyjackson 10mo ago

Its not necessarily fair to use past experience with programming languages that have been seeing major updates year over year. Java as a command line environment has been pretty painless for me, particularly Saxon. Just need to alias the command to include a path to the jre binary. Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.

unlikelytomato 10mo ago

Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years. The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by convention. I would love a rich java ecosystem of TUI/CLI libraries to reuse all of my existing business logic and company libraries. The lack of extremely streamlined wrappers is the only barrier. In my work environment, this would be a great addition.

CamouflagedKiwi 10mo ago
Right, as I said I also think Python has similar issues with startup time. I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.