Fork me on GitHub
#babashka
<
2020-06-16
>
borkdude09:06:34

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

parrot 3
cider 3
Chase19:06:26

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?

Chase19:06:34

I hope that question even makes sense

lukasz19:06:59

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

borkdude19:06:27

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

borkdude19:06:29

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

borkdude20:06:52

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.

dpsutton20:06:05

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

dpsutton20:06:11

not sure how separable it is

borkdude20:06:36

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

dpsutton21:06:14

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

dpsutton21:06:29

i have a very superficial understanding of pods

borkdude21:06:14

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

borkdude21:06:44

this is how you can still implement transactions

dpsutton21:06:47

ah neat. i see.

borkdude21:06:21

btw, there is also https://github.com/borkdude/spartan.spec which can be used as a library

borkdude21:06:15

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

nate22:06:31

Does malli work with babashka?

borkdude22:06:36

it's designed to be GraalVM-compatible so yes

borkdude22:06:17

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

borkdude22:06:30

I would be surprised if it did

nate22:06:55

Oh yeah, forgot about that one.

porkostomus23:06:46

The Exercism Babashka track has been bootstrapped and is preparing for launch: https://github.com/exercism/babashka One thing I am putting a lot of effort into is providing detailed instructions for every editor integration and installation on every platform. https://github.com/exercism/babashka/blob/master/docs/editors.md 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!)