Fork me on GitHub

Added eldoc support to the babashka.nrepl server. binaries from master just appeared in #babashka_circleci_builds / cc @bozhidar

parrot 3
cider 3

So I finally started playing around with babashka. I turned my little temperature converter program into a bb script so trivially I felt I was doing something wrong. It starts instantly! So what is the catch here? As long as I'm not using some library that isn't compatible with graalvm, why wouldn't I use bb for everything? How does the performance compare to using something like lein run on a normal Clojure program?


I hope that question even makes sense


We have a monitoring sidecar deployed in ECS, it's using BB - so you can go pretty far


@chase-lambert The trade-off is startup-time vs performance. For e.g. loops with millions of iterations bb will be slower than the JVM. So it depends what kind of program you're running. Also bb isn't capable of everything yet, e.g. deftype, definterface and reify are constructs that aren't possible in bb yet (but might be one day).


Generally throughput (processing megabytes of data) is also less good in a GraalVM binary like bb than on the JVM.


did a quick, small and probably naive POC with incorporating spec1 into babashka. it does work:

$ ./bb "(require '[clojure.spec.alpha :as s]) (s/def ::a int?) (s/explain-data ::a :foo)"
{:clojure.spec.alpha/problems [{:path [], :pred clojure.core/int?, :val :foo, :via [:user/a], :in []}], :clojure.spec.alpha/spec :user/a, :clojure.spec.alpha/value :foo}
but the binary grows with 35 megabytes (from 60 to 95) and the RAM usage grows also considerably. Might be worth digging into this some more, maybe the spec source can be vendored and curated a little bit, etc. Apart from this, I'm not really sure if I want to incorporate spec1 into bb as spec2 may be coming (soon?, months?, years?) and then moving to that would be breaking.


can there be a separate spec pod for those so inclined?


not sure how separable it is


pods work well with data that can be exchanged as pure edn (or even stateful objects that can be encoded/represented by some edn value and managed on the pod side). for some usage of spec it will work alright, but maybe not for everything


the postgres pods is an example of this? it feels way more class-y and objects rather than edn data


i have a very superficial understanding of pods


yes, I get the confusion. however, database connections are managed by the pod and are exchanged between bb and the pod simply as a map with an identifier in it


this is how you can still implement transactions


ah neat. i see.


btw, there is also which can be used as a library


that's basically a simplified version of spec (without protocols because bb could not interpret those at the time)


Does malli work with babashka?


it's designed to be GraalVM-compatible so yes


oh, you mean as a library? that I don't know, never tried that


I would be surprised if it did


Oh yeah, forgot about that one.

Bobbi Towers23:06:46

The Exercism Babashka track has been bootstrapped and is preparing for launch: One thing I am putting a lot of effort into is providing detailed instructions for every editor integration and installation on every platform. I've done most of them for Linux and am now starting on Windows. My goal is to have one place to refer to to get anyone up and running. (and has already come in handy for me several times!)