@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
I started with a rewrite on the fileset already
it keeps a similar api but the internals are a bit cleaner
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?
@seancorfield yes sir
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?
I think it’s a viable approach and it’s something that keeps coming up
I imagine it as a remote repl kind of situation
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
we also get the option of shifting that to another computer entirely
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 [1]) 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 [1] https://github.com/jeroenvandijk/clojure-scripting
How long do you estimate your builds took when you last used boot?
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.
We don't AOT. We never have.
So a "build" isn't really a thing for us.
We create uberjars (using clj
and my fork of depstar
) but that's pretty quick.
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
Is that inherently a cljs problem?
We tried cljs about four years ago and concluded it was too fragile for production work.
I'm surprised compilation time is still an issue after four years 😞
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!).
I think Boot's fileset abstraction also contributes to the performance problem.
clj
is such a breath of fresh air for us, compared to lein
and boot
.
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)
agreed
we are on the other side of the spectrum, cljs all the way
If you weren't doing cljs -- just clj -- what "build" stuff would you want, that clj
doesn't provide? Just curious there.
the pipeline
Ah, OK. The problem we've "solved" by a small shell script to run clojure
multiple times.
and replacing things like gulp/bower/sass/less with a single tool
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.
yes, I also want to make boot a posibility for clojureCLR users
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
https://github.com/degree9/poshjure/blob/master/poshjure.psm1
Hah, I like how you can just use the clr.api to var
and invoke
like that...
i like how it’s only 30 lines without comments or whitespace XD
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
Well looks like boot is getting funded thanks to Clojurists Together!
https://www.clojuriststogether.org/news/q2-2019-funding-announcement/
Congrats! 💯