This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-16
Channels
- # announcements (8)
- # aws (28)
- # babashka (26)
- # beginners (125)
- # calva (18)
- # chlorine-clover (2)
- # cider (12)
- # cljs-dev (6)
- # cljsrn (4)
- # clojure (134)
- # clojure-europe (31)
- # clojure-italy (2)
- # clojure-nl (14)
- # clojure-uk (83)
- # clojurescript (81)
- # conjure (4)
- # cursive (2)
- # datomic (145)
- # emacs (13)
- # events (3)
- # figwheel-main (14)
- # fulcro (30)
- # graalvm (23)
- # graphql (15)
- # helix (21)
- # jackdaw (20)
- # juxt (1)
- # lambdaisland (4)
- # leiningen (2)
- # malli (12)
- # meander (22)
- # observability (22)
- # off-topic (27)
- # pedestal (3)
- # re-frame (12)
- # reitit (1)
- # releases (2)
- # rewrite-clj (3)
- # shadow-cljs (67)
- # spacemacs (7)
- # sql (1)
- # tools-deps (19)
- # unrepl (2)
- # xtdb (25)
Added eldoc support to the babashka.nrepl server. binaries from master just appeared in #babashka_circleci_builds / cc @bozhidar
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?
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.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
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
btw, there is also https://github.com/borkdude/spartan.spec 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)
A smaller alternative @nate: https://github.com/green-coder/minimallist/tree/master/src/minimallist
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!)