6 ms·

Clojure seems like an odd choice for command line tools. I can see why a committed Clojure programmer would want to reuse their existing skills for a slightly m

Clojure seems like an odd choice for command line tools. I can see why a committed Clojure programmer would want to reuse their existing skills for a slightly mismatching domain. But Rust/Go (even C) would seem like a more obvious choice if you weren't setting off from Clojure as a starting point.

inferiorhuman 7y ago
Why?
bad_user 7y ago
A command-line tool is nothing more than a script that maybe parses some input from the program's arguments or from stdin and then does something useful. Naturally you want to have the libraries you're used to available and the best language for CLI tools is the one you already know. Building CLI tools in C/C++ is silly. If you like Rust/Go, sure, knock yourself out. But the obvious choices are the scripting languages with runtimes that are already distributed as part of the OS .On Linux most CLI tools are built in Python or Perl and Ruby or Node.js are decent choices too. JVM languages aren't an ideal choice due to the startup time, but given the size of the ecosystem you can find a library for pretty much anything you need and now we've got GraalVM to help with the startup time. So not a bad choice either.
- heavenlyblue 7y ago
  >> Python or Perl and Ruby or Node.js Idk - If I wrote a tool in any of those languages and used state-of-the-art features then you would not be able to use them with the system interpreter and you’re back to square one.
- dzamo_norton 7y ago
  That... just ain't so. So many of the GNU programs written for the command line are in C, are performance sensitive and would be crippled by any of the scripting languages you've mentioned. You don't have to look far: grep, sort, sed, find, base64, tar, ...
snorremd 7y ago
Clojure's extensive support for lazy evaluation and sequences actually makes it decent for command line tools that process streams of data. At least in terms of program architecture and elegance. The biggest mismatch used to be startup time, but with GraalVM you can get very good startup times. I made a couple of simple command line programs at my previous workplace and the functional style of Clojure combined with lazy sequences made processing an unknown amount of resources on our server a breeze. I would think that the language of choice for a command line program would have more to do with the task you need the program for and not the command line format itself. Obviously for performance critical stuff such as implementing something like ffmpeg you would want to use rust to squeeze out every last bit of performance.
- slifin 7y ago
  yep, borkdude has been playing with calling Rust from Clojure too via Java JNA, so if most of your application doesn't need rust like performance but one specific part of it does then you're not dead for options
  - Borkdude 7y ago
    Small correction: it's JNI. JNA doesn't work with Graal as far as I know right now.
Heliosmaster 7y ago
You should check Michiel Borkent's work (borkdude): - Babashka: https://github.com/borkdude/babashka https://github.com/borkdude/babashka - Clj-kondo: https://github.com/borkdude/clj-kondo https://github.com/borkdude/clj-kondo - Sci: https://github.com/borkdude/sci https://github.com/borkdude/sci - Jet: https://github.com/borkdude/jet https://github.com/borkdude/jet But again, those are tools (especially babashka) from a Clojurist's perspective
kimi 7y ago
I use it extensively for automating tasks, and it's pretty good. Sure, it's not as snappy as a Go executable, but: 1. you get all JVM libraries (eg JDBC) 2. it's very compact to write and maintain 3. you can develop stuff using a REPL, and this is very handy for ill-defined problems. 4. if the result is worth it, I can create a Graal native for it (but I hardly ever use this) I ended up as an author of a thing to minimize the boilerplate involved: https://github.com/l3nz/cli-matic https://github.com/l3nz/cli-matic

inferiorhuman 7y ago

Why?

bad_user 7y ago

A command-line tool is nothing more than a script that maybe parses some input from the program's arguments or from stdin and then does something useful. Naturally you want to have the libraries you're used to available and the best language for CLI tools is the one you already know. Building CLI tools in C/C++ is silly. If you like Rust/Go, sure, knock yourself out. But the obvious choices are the scripting languages with runtimes that are already distributed as part of the OS .On Linux most CLI tools are built in Python or Perl and Ruby or Node.js are decent choices too. JVM languages aren't an ideal choice due to the startup time, but given the size of the ecosystem you can find a library for pretty much anything you need and now we've got GraalVM to help with the startup time. So not a bad choice either.

heavenlyblue 7y ago
>> Python or Perl and Ruby or Node.js Idk - If I wrote a tool in any of those languages and used state-of-the-art features then you would not be able to use them with the system interpreter and you’re back to square one.
dzamo_norton 7y ago
That... just ain't so. So many of the GNU programs written for the command line are in C, are performance sensitive and would be crippled by any of the scripting languages you've mentioned. You don't have to look far: grep, sort, sed, find, base64, tar, ...

snorremd 7y ago

Clojure's extensive support for lazy evaluation and sequences actually makes it decent for command line tools that process streams of data. At least in terms of program architecture and elegance. The biggest mismatch used to be startup time, but with GraalVM you can get very good startup times. I made a couple of simple command line programs at my previous workplace and the functional style of Clojure combined with lazy sequences made processing an unknown amount of resources on our server a breeze. I would think that the language of choice for a command line program would have more to do with the task you need the program for and not the command line format itself. Obviously for performance critical stuff such as implementing something like ffmpeg you would want to use rust to squeeze out every last bit of performance.

slifin 7y ago
yep, borkdude has been playing with calling Rust from Clojure too via Java JNA, so if most of your application doesn't need rust like performance but one specific part of it does then you're not dead for options
- Borkdude 7y ago
  Small correction: it's JNI. JNA doesn't work with Graal as far as I know right now.

Heliosmaster 7y ago

You should check Michiel Borkent's work (borkdude): - Babashka: https://github.com/borkdude/babashka https://github.com/borkdude/babashka - Clj-kondo: https://github.com/borkdude/clj-kondo https://github.com/borkdude/clj-kondo - Sci: https://github.com/borkdude/sci https://github.com/borkdude/sci - Jet: https://github.com/borkdude/jet https://github.com/borkdude/jet But again, those are tools (especially babashka) from a Clojurist's perspective

kimi 7y ago

I use it extensively for automating tasks, and it's pretty good. Sure, it's not as snappy as a Go executable, but: 1. you get all JVM libraries (eg JDBC) 2. it's very compact to write and maintain 3. you can develop stuff using a REPL, and this is very handy for ill-defined problems. 4. if the result is worth it, I can create a Graal native for it (but I hardly ever use this) I ended up as an author of a thing to minimize the boilerplate involved: https://github.com/l3nz/cli-matic https://github.com/l3nz/cli-matic