I found a useful way to deal with start up times and enable fast command line driven scripting. Start up Clojure and create a socket repl server. Write a bash script that passes a string of Clojure code to netcat, which feeds that into the socket repl server. All the Clojure code embedded in the string does is load a path as a clj file and binds any command line arguments to command-line-args. The arguments are pulled by the bash script and inserted in the string of Clojure code. With the bash script in your path, you can now add #!/usr/bin/env name-of-bash-script-in-path at the top of any clj file, make the file executable, and then execute it instantly like any other bash script but now the full power of Clojure.

I found it useful to override the print and prompt method so that they are silent, requiring the script to explicitly print to stdout/stderr if desired. I reuse the socket-repl reader to enable exiting via :repl/quit which is echoed in the bash script after the script is loaded.

The obvious downside is you have to start at "server" before any of this works but I think the main interface limitation was the inability to interact with Clojure from the command-line and with other command-line tools.

If this is a major concern for you, there are several clojurescript projects--Planck and Lumo--that have very fast startup. JVM Clojure is a bit faster than jsc/node clojurescript (~2x IIRC) but that shouldn't matter much for scripting/automation and lambda functions or equivalent on other clouds.

In that case... what about just regular plain old Common Lisp?

I'm not intending to criticize Common Lisp, which I loved back in the early 90's, but there are things to like about Clojure over Common Lisp.

The word you were looking for is "immutability".

Such as?

A big one is persistent data structures. Where 'persistent' may not mean what you think it means.

In Clojure it is impossible to surgically modify a data structure. That is, you can't do something like:

(SETF (CAR (CDR x)) 'foo)

which would alter a data structure.

You can modify a data structure, but it returns a new data structure, yet the old one remains if it is not GC'able.

All of the common data structures have this property. Sequences (eg, lists), arrays, maps and sets. If you change the 50 thousandth element of an array, this returns a new array. The old array is unaffected. Yet it gives the performance you expect of an array. (Meaning no apparent cost of copying.)

If you're writing a search procedure, it is trivial to transform one chessboard into a different chessboard, but without concern about the cost of copying (close to zero), or having altered the original value (you haven't). Other variables that have a pointer to that first chessboard don't see any changes.

There are other things such as a great story about concurrency.

Hope that helps.

It should be noted that you can even if you in 99.9% of cases don't want to mutate state.

For the few times when you want to squeeze the last drop of performance, you can use transients[0].

[0] https://clojure.org/reference/transients

How is the cost of copying close to zero or not apparent?

The data structures in Clojure are built on shallow 32-way trees. When you "change" a map or a vector, the algorithm only copies from the root node down to the parent of the leaf you're changing. That's log32(N) copied nodes in a tree of N nodes total.

Because persistent data structures that use structural sharing.

Good answers by others. The cost it not quite zero, but very close. The benefits this buys are huge. The obvious case is recursive search algorithms.

I'll give you another. Laziness. It's built in. It's trivial to create lazy lists that generate their contents as you walk down the list. Even infinite lazy lists. The list of all prime numbers. The list of all fibonacci numbers.

You can use map, which if I remember my CL, is like MAPCAR. But instead of map, you can use pmap which will do the processing on all of your cpu cores.

pmap in CL is one library away, along with preduce, ... (https://lparallel.org/).

Is it lazy?

Of course not, lazy is opt-in in CL, that wouldn't be idiomatic.

Besides, the semi-lazy approach of Clojure's pmap (allocate futures consecutively) doesn't seem to convince everyone:

https://stackoverflow.com/questions/2103599/better-alternati...

https://www.reddit.com/r/Clojure/comments/20lxmv/just_what_i...

On the one hand, when you want to parallelize, you are delegating tasks to workers and you want them to do what they need, independently of you. But on the other hand, laziness introduce a dependency from you, because workers cannot produce a result before they are sure you really need it. This basically slows down parallelization and that's why I am not sure Clojure's pmap is a good general solution.

Note that Clojure Reducers, mentioned here in Zombie Metaphysics (ppmap: http://www.braveclojure.com/zombie-metaphysics) and documented at https://clojure.org/reference/reducers, use strict sequences.

Laziness is great when you need it, but when you don't you shouldn't have to pay for it.

http://clojure.com/blog/2012/05/08/reducers-a-library-and-mo...

Not having separate namespaces for values and functions ;-)

Well, ClojureScript will run just fine on Node.js. It fills the same niche, it seems.

It sounds nice right?