I’m not associated with kscript, but after trying it I want to post that I recommend taking a look.
I was skeptical after looking at the implementation ( a fairly complex looking shell script) that it would be any
better, especially performance, then Atlan’s suggestion (which works fine and does with in simplicity points).
But a simple ‘1 liner’ test (and then an hour later not-so-simple because I didn’t believe it) –
Put the above in a file ( I had to change to ‘#!/my/path/to/kotlinc -script’) /tmp/file.kts
then try a simple test:
Run that a few times
Then delete the first line (the shebang) and try again with kscript
For me - the very first run of kscripts was infinitesimally longer (added about .001s)
But after that 10-40x shorter every run (depends on script complexity and what its doing).
Using kotlinc directly makes no measurable difference.
Note the user time – 4.377 sec for kotlnc, .145 for kscript. > 30x diff
That’s why I didn’t believe it kscript is a 1 file shell script – its not doing anything really fancy or complicated - nothing you can’t do yourself or do without - except convenience … but I doubt I could do better easily so Im not going to bother.
Leaving the ‘pre-compiled’ script cached is a huge win – if you are using a script more than once. If you are not, its still a big win because the performance and simplicity is equivalent but you don’t have to do things differently each time.
JVM startup time is bad enough that it makes JVM CLI apps non-performant in many scripting use cases,
add to that the compile startup time and now looking at 2+ maybe FIVE secs per invocation – that pushes it over the line
for ‘no brainer’ script replacements – put that in a for loop or multiple $(script) calls and your simple scripts take minutes instead of seconds or less. Dropping that down to a .1s appx startup overhead brings it back to the realm of reasonable ‘no brainer’ script use cases.
Maybe someday kotlin will optimize the startup - until then, I’m going with kscript