4 ms·
This post could be summarized as "write as much of your project's tooling as you can in the project's main programming language and the project's main programmi
by tomconnors 5y ago
This post could be summarized as "write as much of your project's tooling as you can in the project's main programming language and the project's main programming language should be Clojure" and I agree wholeheartedly.
- blacktriangle 5y agoI think their point is bigger than that. Historically one of the major points against using Clojure to write your tooling was the slow startup times which are just painful from the CLI. It looks like the clj-exec idea linked to in the article is the secret sauce that makes moving to writing your tooling in Clojure a workable idea, since now you have a unified calling convention for both calling tooling from the REPL during development but also activating your tooling from the CLI in some CI or build pipeline where the massive Clojure startup times don't matter. This article comes at a perfect time, we're just starting a new Clojure project and were looking into how to automate tooling since we'd been burned by Clojure startup times before. Looks like clj-exec means we can now unify our work on Clojure.
- Borkdude 5y agoAlso check out https://babashka.org https://babashka.org: it offers Clojure scripting with very fast startup time. It also has a task runner (similar to make, just, etc.) that can be used to store long invocations (like clj-exec tends to have).
- utxaa 5y agowhat about the horrible debugging experience?
- kinjba11 5y agoDoes GraalVM work with Clojure? I would assume that would solve the startup time issue for a project like a CLI tool.
- toomanybeersies 5y agoThe general gist of the article also applies to Ruby too.