8 ms·

Using Clojure in the command line with Babashka

152 points by Borkdude 6y ago

ilikehurdles 6y ago
We've been writing clojure cli utilities a lot since babashka came out. It's really nice killing some of our reliance on bash.
- jakebasile 6y ago
  Yeah, babashka has become our go-to form of scripting in the past 6 months or so. Super handy!
jonahbenton 6y ago
This is one of those tools that proves that explicitly solving for ergonomics really makes a huge difference.
Scarbutt 6y ago
He concludes that Python is just more practical and superior for these scripting tasks but went through all the trouble because he likes Clojure.
- phyrex 6y ago
  That is not the conclusion at all. Literally the conclusion: > It’s nice to have another scripting tool in my toolbox: Babashka. Time will tell if I start using Clojure instead of Python as my preferred scripting language, thanks to Babashka. At least in this exercise Babashka did really well.
- submeta 6y ago
  Actually, „because he likes the language“ is a good enough reason. At least for someone with a hacker spirit. Liking a languange will motivate me more to look into all corners of that language and put my heart in exploring it instead of knowing as much as I need to get the job done.
- happyrock 6y ago
  (this commenter shows up in most Clojure threads, to bash Clojure)
dannyobrien 6y ago
I've been looking again at Clojure recently, and it seems to have that feature of lisps that their language feature-set seems to just settle over time; unlike Javascript and even Python, it's pretty much the same as it was a few years ago. Instead, it's implementations like Babashka that are providing most of the innovation. I think this is a good thing! Though I do worry a bit that Clojure can look more moribund than it is. I see a lot of people exploring the language for the first time saying "this tutorial is from 2013, is it still valid?". The answer is mostly yes, but with some changes in tooling that can be dispiriting for beginners, and may make them think the whole ecosystem has gone rusty.
- capableweb 6y ago
  I think this tends to happen to all lisps, at one point or another. Many new language features in lisp languages don't have to be added to the compiler itself and can instead be distributed as libraries. Compared to JavaScript and others, where if you want something new, it has to go through the compiler/VM/interpreter.
- stingraycharles 6y ago
  It’s pretty much by design, as the syntax and standard libraries with lispS are intentionally small. In other languages, you see new language syntax or semantics being added, while in a lisp it’s pretty much unheard of to change the syntax, there’s so little to change. Macros can do a lot of stuff, and as such libraries themselves can add pretty elaborate functionality. Having said all this, what I do notice with my experience of Clojure is that there are certain “trends” in how you write code. The language itself may not evolve that much, but the styles people write code in it, and how they solve problems, certainly does.
  - vapapav 6y ago
    I've been using Clojure in isolation and I have "style anxiety". Can you elaborate (or point me somewhere) on the trends and changes in style you've observed? Thanks!
    - 6y ago
pixelmonkey 6y ago
This is a nice post. I wrote my own exploration of bb (Babashka) recently here, and it includes some comparisons to Python and JVM Clojure as well: https://amontalenti.com/2020/07/11/babashka https://amontalenti.com/2020/07/11/babashka
deleted 6y ago
[deleted]
- deleted 6y ago
  [deleted]
CraigJPerry 6y ago
Clojure is a recurring gravitational pull for me. I haven't had time to properly explore yet but I will before end of year. It's not a "first" language like JS, Python, Java, C#, Ruby etc. so the community appears to benefit from a higher than average level of skill. In the same way that i imagine Erlang or Elixir might enjoy the benefit of more capable than average users. The fact that entire paradigms can be implemented as libraries is attractive to me - it suggests to me that the Python 3000 or C++11 problems are unlikely to affect Clojure. For example, Go is a language I find interesting. The whole CSP concept makes a ton of sense to me in writing enterprise software - mainly from a "keeping the architecture cheap to own and change over time" point of view. I appreciate this isn't where CSP was targeted but it lends itself very well IMO to solving this problem because you could decouple components and grow them independently so effectively. Go is an entire language but core.async is just a library in Clojure, they didn't have to change the language to implement this which is mind blowing to me. Another example is types. Only some of the code I write actually benefits from types AND most type systems in "enterprise" languages are pretty anaemic. Typing is also really hard to do well, like really really hard. You had a problem, you adopted typing and now you have two problems is generally my thinking here. Scala was to be my saviour here but that missed the mark quite spectacularly and the compiler is still ridiculously slow today but then along came TypeScript which is pretty darned awesome IMO. Thanks to TypeScript and modern Python i had learned that i wanted "optional typing" and i was undecided about type erasure at runtime - i don't immediately see a problem with it, i've written probably thousands of lines of Java with generics then used reflection at runtime without losing sleep, but it fills an awkward space in my head - to invest in types but only benefit at compile time seems like a miss. In Clojure i can follow the TypeScript model but actually take it further to runtime. This post is too long already. Long way to say Clojure appears very interesting.
- kuberlog 6y ago
  > Clojure is a recurring gravitational pull for me. You're in love
  - microcolonel 6y ago
    After working with it for a couple years now, I still really appreciate it.
praptak 6y ago
For me the most interesting part is how it gets rid of the JVM startup time. So there are two parts to the solution: The first part is Small Clojure Interpreter (sci) which is a "(subset of) Clojure written in Clojure", so kind of McCarthy for Clojure. A cool project in itself but it still needs a VM to run. So here is where the second part comes in: the GraalVM produces native binaries from various things, including Clojure code and SCI is simple enough to work with GraalVM. It's cool how these two pieces of tech combine together to create something greater than the sum of the parts.
- auganov 6y ago
  A slightly simpler explanation: GraalVM solves the startup time but clojure's built-in eval wouldn't work after compilation so you need to reimplement it in a simpler way.
  - michaelsbradley 6y ago
    Are you certain that’s the case? See: https://github.com/BrunoBonacci/graalvm-clojure#readme https://github.com/BrunoBonacci/graalvm-clojure#readme
    - fulafel 6y ago
      That's a table of library compatibility w/ GraalVM, one reason for incompatibility can be use of runtime evaluation.
      - tincholio 6y ago
        I think it's related to dynamic loading of classes (and since Clojure functions get compiled to classes, this might be the issue), not really evaluation per se. But I haven't really looked at Graal native image for a while, so I'm not sure what's the current status.
- invisiblerobot 6y ago
  The startup time of the jvm is negligible. This myth keeps coming up. Most of the startup time is Clojure itself.
agumonkey 6y ago
Seeing this makes me wonder if a concatenative/stack (factor?) variant wouldn't be even better. For small script .. when you need larger you go full lisp. ps: just installed it on my old core i3.. and omg, this loads faster than sbcl.
- deleted 6y ago
  [deleted]
dimitar 6y ago
BB is really cool, I just used it to run an ETL-type process I wrote, and I didn't had to change the Clojure program at all. Also, the built-in batteries were just what I was using anyway (JSON parsing most importantly).
didibus 6y ago
Babashka is only half the magic. It is built up from SCI (small Clojure interpreter). Which is a Clojure interpreter written in Clojure. That's super cool! Sci is awesome, and it allows you to create custom Clojure interpreters with whatever subset of Clojure + any additional functions and macros of your liking.

152 points by Borkdude 6y ago

We've been writing clojure cli utilities a lot since babashka came out. It's really nice killing some of our reliance on bash.

jakebasile 6y ago
Yeah, babashka has become our go-to form of scripting in the past 6 months or so. Super handy!

jonahbenton 6y ago

This is one of those tools that proves that explicitly solving for ergonomics really makes a huge difference.

Scarbutt 6y ago

He concludes that Python is just more practical and superior for these scripting tasks but went through all the trouble because he likes Clojure.

phyrex 6y ago
That is not the conclusion at all. Literally the conclusion: > It’s nice to have another scripting tool in my toolbox: Babashka. Time will tell if I start using Clojure instead of Python as my preferred scripting language, thanks to Babashka. At least in this exercise Babashka did really well.
submeta 6y ago
Actually, „because he likes the language“ is a good enough reason. At least for someone with a hacker spirit. Liking a languange will motivate me more to look into all corners of that language and put my heart in exploring it instead of knowing as much as I need to get the job done.
happyrock 6y ago
(this commenter shows up in most Clojure threads, to bash Clojure)

dannyobrien 6y ago

I've been looking again at Clojure recently, and it seems to have that feature of lisps that their language feature-set seems to just settle over time; unlike Javascript and even Python, it's pretty much the same as it was a few years ago. Instead, it's implementations like Babashka that are providing most of the innovation. I think this is a good thing! Though I do worry a bit that Clojure can look more moribund than it is. I see a lot of people exploring the language for the first time saying "this tutorial is from 2013, is it still valid?". The answer is mostly yes, but with some changes in tooling that can be dispiriting for beginners, and may make them think the whole ecosystem has gone rusty.

capableweb 6y ago
I think this tends to happen to all lisps, at one point or another. Many new language features in lisp languages don't have to be added to the compiler itself and can instead be distributed as libraries. Compared to JavaScript and others, where if you want something new, it has to go through the compiler/VM/interpreter.
stingraycharles 6y ago
It’s pretty much by design, as the syntax and standard libraries with lispS are intentionally small. In other languages, you see new language syntax or semantics being added, while in a lisp it’s pretty much unheard of to change the syntax, there’s so little to change. Macros can do a lot of stuff, and as such libraries themselves can add pretty elaborate functionality. Having said all this, what I do notice with my experience of Clojure is that there are certain “trends” in how you write code. The language itself may not evolve that much, but the styles people write code in it, and how they solve problems, certainly does.
- vapapav 6y ago
  I've been using Clojure in isolation and I have "style anxiety". Can you elaborate (or point me somewhere) on the trends and changes in style you've observed? Thanks!
  - 6y ago

pixelmonkey 6y ago

This is a nice post. I wrote my own exploration of bb (Babashka) recently here, and it includes some comparisons to Python and JVM Clojure as well: https://amontalenti.com/2020/07/11/babashka https://amontalenti.com/2020/07/11/babashka

deleted 6y ago

[deleted]

deleted 6y ago
[deleted]

CraigJPerry 6y ago

Clojure is a recurring gravitational pull for me. I haven't had time to properly explore yet but I will before end of year. It's not a "first" language like JS, Python, Java, C#, Ruby etc. so the community appears to benefit from a higher than average level of skill. In the same way that i imagine Erlang or Elixir might enjoy the benefit of more capable than average users. The fact that entire paradigms can be implemented as libraries is attractive to me - it suggests to me that the Python 3000 or C++11 problems are unlikely to affect Clojure. For example, Go is a language I find interesting. The whole CSP concept makes a ton of sense to me in writing enterprise software - mainly from a "keeping the architecture cheap to own and change over time" point of view. I appreciate this isn't where CSP was targeted but it lends itself very well IMO to solving this problem because you could decouple components and grow them independently so effectively. Go is an entire language but core.async is just a library in Clojure, they didn't have to change the language to implement this which is mind blowing to me. Another example is types. Only some of the code I write actually benefits from types AND most type systems in "enterprise" languages are pretty anaemic. Typing is also really hard to do well, like really really hard. You had a problem, you adopted typing and now you have two problems is generally my thinking here. Scala was to be my saviour here but that missed the mark quite spectacularly and the compiler is still ridiculously slow today but then along came TypeScript which is pretty darned awesome IMO. Thanks to TypeScript and modern Python i had learned that i wanted "optional typing" and i was undecided about type erasure at runtime - i don't immediately see a problem with it, i've written probably thousands of lines of Java with generics then used reflection at runtime without losing sleep, but it fills an awkward space in my head - to invest in types but only benefit at compile time seems like a miss. In Clojure i can follow the TypeScript model but actually take it further to runtime. This post is too long already. Long way to say Clojure appears very interesting.

kuberlog 6y ago
> Clojure is a recurring gravitational pull for me. You're in love
- microcolonel 6y ago
  After working with it for a couple years now, I still really appreciate it.

praptak 6y ago

For me the most interesting part is how it gets rid of the JVM startup time. So there are two parts to the solution: The first part is Small Clojure Interpreter (sci) which is a "(subset of) Clojure written in Clojure", so kind of McCarthy for Clojure. A cool project in itself but it still needs a VM to run. So here is where the second part comes in: the GraalVM produces native binaries from various things, including Clojure code and SCI is simple enough to work with GraalVM. It's cool how these two pieces of tech combine together to create something greater than the sum of the parts.

auganov 6y ago
A slightly simpler explanation: GraalVM solves the startup time but clojure's built-in eval wouldn't work after compilation so you need to reimplement it in a simpler way.
- michaelsbradley 6y ago
  Are you certain that’s the case? See: https://github.com/BrunoBonacci/graalvm-clojure#readme https://github.com/BrunoBonacci/graalvm-clojure#readme
  - fulafel 6y ago
    That's a table of library compatibility w/ GraalVM, one reason for incompatibility can be use of runtime evaluation.
    - tincholio 6y ago
      I think it's related to dynamic loading of classes (and since Clojure functions get compiled to classes, this might be the issue), not really evaluation per se. But I haven't really looked at Graal native image for a while, so I'm not sure what's the current status.
invisiblerobot 6y ago
The startup time of the jvm is negligible. This myth keeps coming up. Most of the startup time is Clojure itself.

agumonkey 6y ago

Seeing this makes me wonder if a concatenative/stack (factor?) variant wouldn't be even better. For small script .. when you need larger you go full lisp. ps: just installed it on my old core i3.. and omg, this loads faster than sbcl.

deleted 6y ago
[deleted]

dimitar 6y ago

BB is really cool, I just used it to run an ETL-type process I wrote, and I didn't had to change the Clojure program at all. Also, the built-in batteries were just what I was using anyway (JSON parsing most importantly).

didibus 6y ago

Babashka is only half the magic. It is built up from SCI (small Clojure interpreter). Which is a Clojure interpreter written in Clojure. That's super cool! Sci is awesome, and it allows you to create custom Clojure interpreters with whatever subset of Clojure + any additional functions and macros of your liking.