Hacker News Reader

Comment by inferiorhuman | Hacker News Reader

What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it.

The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback hell.

Ultimately rust (and go to some extent) seemed to fit my use cases better.

If I had to do a web app from scratch I would think long and hard about going Clojure if only because it leverages such a widely used VM. Points 1 & 2 weren't issues for me, but #3 was (and there are similar problems with Elixir).

View on HN

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.

Why?

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.

>> 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.

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, ...

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.

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

Small correction: it's JNI. JNA doesn't work with Graal as far as I know right now.

You should check Michiel Borkent's work (borkdude):

- Babashka: https://github.com/borkdude/babashka

- Clj-kondo: https://github.com/borkdude/clj-kondo

- Sci: https://github.com/borkdude/sci

- Jet: https://github.com/borkdude/jet

But again, those are tools (especially babashka) from a Clojurist's perspective

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

Nowadays you can use GraalVM to have quick startup time for commandline tools with Clojure.

KNow of any good tutorials for how to use Graal with Clojure?

https://github.com/lread/clj-graal-docs

Thanks! Took a while, but I got this working on Linux. Gave up on Windows, like with everything it never seems to work on Windows.

End result is 8.1MB for "hello world".

Windows can run Linux binaries now :)

Is Rust better in the browser wrt "callback hell" in your view?

In ClojureScript you can use core.async to write async code in straight-line form. But I find myself using it pretty seldom, as handling events explicitly in functions feels pretty natural in Clojure especially given how naturally closures work in the language.

Reply on news.ycombinator.com