no dependency management (apart from an error message: ztf not found)
one file that does everything
no build system
no IDE support (vim should be enough for everybody)
no unit tests
no CI/CD
The biggest issue with writing a CLI in a JVM language is no one wants to run a CLI via a JVM, download Gradle (even with the wrapper), etc which wasn't really addressed here. The selling point of bash is it runs natively.
I'm confused "biggest issue with writing a CLI in a JVM language" comment. If a dev is already doing Kotlin wouldn't writing CLI tools in a language they are familiar with be useful? When the target is native, you don't need a JVM to run the resultant code.
Aren't you fairly limited in the libraries you can use when building native though? Is being restrict to C library wrappers really better than canonic GNU programs?
I would say this is a matter of how comfortable one is using bash versus how comfortable one is using Kotlin. As someone who uses Kotlin on the regular, I can visualize the business logic better in that language and the developer tools are more familiar to me. Additionally, if your CLI tool is doing less interaction with GNU tools and more processing and you are very comfortable with Kotlin then Kotlin CLI might be more for you... especially if you don't need to write a lot of CLI tools. Also if you are writing a tool that is targeted to multi-platform then this is exactly what you want to do if Kotlin is your primary language as you would only need to write the business logic once.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
There are shell scripts who do all of this, and there are flying fishes, but that's not the majority of the species!
Gradle and the JVM are only needed for building the tool.
After, if you use Kotlin/JS, only node is required, and if you use Kotlin/native, nothing is required
The thing is, you can compile it to a native exe
a native windows exe
a native MacOS exe
a native linux exe
if you ever watched a bash script running for 24 minutes and then fail
because again you forgot some single/double quotes or parenthesises or 3times-escapes, then you start value strongly typed languages ... and HashMaps ... and lambdas ... and and and ...
None of these things are strictly true.
no dependency management (apart from an error message: ztf not found)
one file that does everything
no build system
no IDE support (vim should be enough for everybody)
no unit tests
no CI/CD
The biggest issue with writing a CLI in a JVM language is no one wants to run a CLI via a JVM, download Gradle (even with the wrapper), etc which wasn't really addressed here. The selling point of bash is it runs natively.
I'm confused "biggest issue with writing a CLI in a JVM language" comment. If a dev is already doing Kotlin wouldn't writing CLI tools in a language they are familiar with be useful? When the target is native, you don't need a JVM to run the resultant code.
Aren't you fairly limited in the libraries you can use when building native though? Is being restrict to C library wrappers really better than canonic GNU programs?
I would say this is a matter of how comfortable one is using bash versus how comfortable one is using Kotlin. As someone who uses Kotlin on the regular, I can visualize the business logic better in that language and the developer tools are more familiar to me. Additionally, if your CLI tool is doing less interaction with GNU tools and more processing and you are very comfortable with Kotlin then Kotlin CLI might be more for you... especially if you don't need to write a lot of CLI tools. Also if you are writing a tool that is targeted to multi-platform then this is exactly what you want to do if Kotlin is your primary language as you would only need to write the business logic once.
But I agree with your statement in general.
There are shell scripts who do all of this, and there are flying fishes, but that's not the majority of the species!
Gradle and the JVM are only needed for building the tool.
After, if you use Kotlin/JS, only node is required, and if you use Kotlin/native, nothing is required
The thing is, you can compile it to a native exe
a native windows exe
a native MacOS exe
a native linux exe
if you ever watched a bash script running for 24 minutes and then fail
because again you forgot some single/double quotes or parenthesises or 3times-escapes, then you start value strongly typed languages ... and HashMaps ... and lambdas ... and and and ...
or use github.com/holgerbrandl/kscript
without all the gradle, Intellij, etc. stuff