Fork me on GitHub
#boot
<
2019-04-30
>
flyboarder02:04:40

@dave I would start with a simple client server architecture on top of the clojure cli tool

flyboarder02:04:13

ideally the client should be able to start on the cli tool and on a bootstrap based native image

flyboarder02:04:13

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

flyboarder02:04:34

the server is the harder part as we need to overhaul the fileset and pod architectures

flyboarder02:04:48

I started with a rewrite on the fileset already

flyboarder02:04:11

it keeps a similar api but the internals are a bit cleaner

flyboarder02:04:27

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

seancorfield03:04:31

@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?

seancorfield05:04:29

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?

flyboarder05:04:38

I think it’s a viable approach and it’s something that keeps coming up

flyboarder05:04:21

I imagine it as a remote repl kind of situation

flyboarder05:04:30

the jvm has a huge startup cost, which compared to something like nodejs, has a terrible developer experience when running cli based tools

👍 1
flyboarder05:04:11

by shifting the build processing to a “server”, we can drastically reduce the cost of repeated startups

flyboarder05:04:31

we also get the option of shifting that to another computer entirely

flyboarder05:04:05

such as a compilation service for clojure code, where you have a local client and some really powerful build box

seancorfield05:04:10

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

jeroenvandijk07:04:41

@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

flyboarder05:04:01

How long do you estimate your builds took when you last used boot?

seancorfield05:04:01

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.

seancorfield05:04:16

We don't AOT. We never have.

seancorfield05:04:29

So a "build" isn't really a thing for us.

seancorfield05:04:51

We create uberjars (using clj and my fork of depstar) but that's pretty quick.

flyboarder05:04:26

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

seancorfield05:04:45

Is that inherently a cljs problem?

seancorfield05:04:05

We tried cljs about four years ago and concluded it was too fragile for production work.

seancorfield05:04:23

I'm surprised compilation time is still an issue after four years 😞

flyboarder05:04:27

Often I work across many projects which are related, each their own boot project, so I am restarting boot all day long

flyboarder05:04:17

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

👍 1
seancorfield05:04:31

But Boot itself is pretty heavy to start up. It contains a lot of code. Leiningen is too (and it starts two JVMs!).

seancorfield05:04:51

I think Boot's fileset abstraction also contributes to the performance problem.

seancorfield05:04:11

clj is such a breath of fresh air for us, compared to lein and boot.

seancorfield05:04:43

But, yeah, I'll concede that pure-clj avoids some of the pain I keep hearing from cljs users 🙂

flyboarder05:04:03

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

flyboarder05:04:19

I completely understand why you would use it if you are only using clojure in your apps

seancorfield05:04:42

(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)

flyboarder05:04:05

we are on the other side of the spectrum, cljs all the way

seancorfield05:04:35

If you weren't doing cljs -- just clj -- what "build" stuff would you want, that clj doesn't provide? Just curious there.

flyboarder05:04:53

the pipeline

seancorfield05:04:19

Ah, OK. The problem we've "solved" by a small shell script to run clojure multiple times.

flyboarder05:04:37

and replacing things like gulp/bower/sass/less with a single tool

seancorfield05:04:28

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.

flyboarder05:04:01

yes, I also want to make boot a posibility for clojureCLR users

seancorfield05:04:01

I watch our front end team struggle with the wild west of build tools etc -- and they're doing pure JS (React.js etc).

seancorfield05:04:38

ClojureCLR seems to be generating a bit more buzz lately. Mr Miller is a powerhouse.

flyboarder05:04:10

if I could just use boot for the clr I would be the happiest person, powershell still doesnt do it for me

flyboarder05:04:39

I dont want to have to use powershell or c# I want the same clojure experience on windows

seancorfield05:04:03

We have a PS version of the clojure *nix script now 🙂 For JVM Clojure of course 😉

flyboarder05:04:52

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

seancorfield05:04:53

Hah, I like how you can just use the clr.api to var and invoke like that...

flyboarder05:04:59

i like how it’s only 30 lines without comments or whitespace XD

flyboarder05:04:54

it’s so easy to get started with clojure on clr and very difficult to make anything complex

seancorfield05:04:38

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 🙂

seancorfield05:04:43

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

flyboarder05:04:43

thats so interesting, for cljs projects even my complex ones have a super simple build.boot

flyboarder05:04:14

I wrote a boot-shadow task for that exact thing, we have been using it in production for 6 months now

flyboarder05:04:13

shadow is great for cljs compiling, but again falls short for the rest of our pipeline

flyboarder22:04:43

Well looks like boot is getting funded thanks to Clojurists Together!

🎉 10
boot-clj 2
seancorfield22:04:00

Congrats! 💯