This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (7)
- # beginners (103)
- # boot (62)
- # cider (14)
- # clara (10)
- # cljdoc (4)
- # cljs-dev (2)
- # cljsrn (2)
- # clojure (51)
- # clojure-dev (15)
- # clojure-europe (13)
- # clojure-italy (25)
- # clojure-japan (3)
- # clojure-nl (4)
- # clojure-spec (6)
- # clojure-uk (9)
- # clojurescript (72)
- # clojureverse-ops (2)
- # community-development (2)
- # core-async (35)
- # cursive (16)
- # datascript (1)
- # datomic (12)
- # duct (2)
- # emacs (2)
- # fulcro (9)
- # graphql (5)
- # hoplon (5)
- # leiningen (3)
- # luminus (1)
- # nyc (1)
- # off-topic (41)
- # other-languages (1)
- # pathom (16)
- # pedestal (2)
- # re-frame (44)
- # reitit (1)
- # shadow-cljs (33)
- # spacemacs (12)
- # test-check (9)
- # tools-deps (15)
- # vim (4)
@dave I would start with a simple client server architecture on top of the clojure cli tool
ideally the client should be able to start on the cli tool and on a
bootstrap based native image
so we should assume in each case that the required bit’s would be provided by those platforms, and all that’s needed is implementing the client
the server is the harder part as we need to overhaul the fileset and pod architectures
my thought around the server design is that we have a new http://boot.app namespace which creates the initial “core” pod, then it spins up additional pods as boot clients connect and send over their boot.properties
@flyboarder Is the main driver for that to have a persistent pod-based Clojure "engine" that can support short-lived client commands with very fast startup? i.e., all about avoiding the JVM startup overhead?
I've seen a number of those sort of things over the years but none of them seem to have gone mainstream -- are you sure it's not a solution in search of a problem?
the jvm has a huge startup cost, which compared to something like nodejs, has a terrible developer experience when running cli based tools
by shifting the build processing to a “server”, we can drastically reduce the cost of repeated startups
such as a compilation service for clojure code, where you have a local client and some really powerful build box
I guess I remain unconvinced. I've been doing Clojure for nine years now, eight in production, and we have 82,000 lines of code in a monorepo with 30-ish subprojects, and startup time -- every for our command-line tools in all that -- really isn't a problem. Sure, it's a minor annoyance occasionally, but I don't yearn for some "server" process that stays hot for all the things I'm doing...
@seancorfield I had the same feeling until I created a prototype with Clojure (a client/server setup ) that runs scripts under 30ms like any other bash or python script. The client is compiled with GraalVM which makes it fast, the server is a prepl. It might not be for everything but for a case where startup time matters this could make Clojure viable  https://github.com/jeroenvandijk/clojure-scripting
The vast majority of my workflow is based around a live REPL that I startup and leave running for days (or even weeks). I load code (compile), run tests, no startup cost involved.
ok, so for my apps I am building cljs client/server projects, currently our builds take about 60 seconds every time I save a file
We tried cljs about four years ago and concluded it was too fragile for production work.
Often I work across many projects which are related, each their own boot project, so I am restarting boot all day long
waiting 3 minutes for a working build ready for code changes and then waiting another minute every time I make a meaningful change is rather difficult
But Boot itself is pretty heavy to start up. It contains a lot of code. Leiningen is too (and it starts two JVMs!).
But, yeah, I'll concede that pure-clj avoids some of the pain I keep hearing from cljs users 🙂
my problem with clj is that it’s not a build tool and doesn’t take into account everything unrelated to the clojure aspects of my poject
I completely understand why you would use it if you are only using clojure in your apps
(and this sort of discussion is important to me because at some point we'll start using cljs again -- but it needs to solve these problems first)
If you weren't doing cljs -- just clj -- what "build" stuff would you want, that
clj doesn't provide? Just curious there.
Ah, OK. The problem we've "solved" by a small shell script to run
clojure multiple times.
For cljs, it seems a bit hamstrung by still depending on the JVM/Google Closure etc. So, yeah, I can see that. The front end ecosystem is such a mess IMO.
I watch our front end team struggle with the wild west of build tools etc -- and they're doing pure JS (React.js etc).
ClojureCLR seems to be generating a bit more buzz lately. Mr Miller is a powerhouse.
if I could just use boot for the clr I would be the happiest person, powershell still doesnt do it for me
I dont want to have to use powershell or c# I want the same clojure experience on windows
We have a PS version of the
clojure *nix script now 🙂 For JVM Clojure of course 😉
I wrote a thing for clojureCLR in powershell, it’s ok for scripts but it made me realize I need a build tool to get anything really meaningful past that
it’s so easy to get started with clojure on clr and very difficult to make anything complex
I'll be interested to see how all this plays out --
boot was such a huge improvement over
lein when we switched back in 2015 but we just got bogged down in it all the more we built with it. We ended up with a 2,000 line
build.boot file 🙂
For us to even consider anything serious with cljs in the future, the tooling needs to be sorted out, so I can see a definitely window there for Boot -- but shadows-cljs seems to have a solid foothold (I use that for hacking on Chlorine, the plugin for Atom).
thats so interesting, for cljs projects even my complex ones have a super simple build.boot
I wrote a boot-shadow task for that exact thing, we have been using it in production for 6 months now
shadow is great for cljs compiling, but again falls short for the rest of our pipeline