Jaunt is dead. What next?

[arrdem]

I'm calling it. Jaunt's dead in the water.

There are a variety of reasons for this. I made too many changes. I didn't bake some of them well. Clojure is a very complex code base and I hit a number of walls when I tried to do various things. Things that should have worked didn't for strange reasons.

Ultimately, nobody else (with thanks to @danielcompton) ever really stepped up with ideas about what a "better Clojure" would look like. Despite grousing, the overwhelming majority of Clojure's community seems content with current leadership and direction (or lack thereof). As evidenced now by the bleached bones of Dunaj and Jaunt, there simply isn't a market for a "community" fork although many institutions operate their own internal Clojure forks.

For me, ox-lang/ox is next. It's a clean break. It's easier to work on without getting frustrated at the Clojure core or its various cultural baggage. It fits in my head and is a nice release at the end of the day.

I'd be pleased to hand Jaunt off to other maintainership, and would appreciate feedback on whether it's valuable to the Clojure community to leave this as a cultural artifact / warning to the wise or whether I should just shut it down.

[plexus]

Thanks @arrdem for trying to making things better and challenging the status quo. I'm sorry to see Jaunt go this way, I think simply having these forks to demonstrate alternative ways forward is part of a healthy ecosystem. Good luck with Ox! I'm curious to see where that will go.

One thing I'm curious about: did you have any particular successes with Jaunt? Changes or improvements that really turned out well? Any hard earned lessons for the next person treading this path?

[arrdem]

• Versioning namespaces was an attempt to find a halfway point between immutable namespaces and the Clojure status quo of fully mutable namespaces. It turns out there are lots of subtleties here and that there are interesting ways that Vars can become "stale" (but still work!) due to partial code reloading and even common/idiomatic use. That is, versioned namespace and stale var warnings generated too many false positives to really have good ergonomics. I think you really have to go whole-hog immutable environments which is what Mikera's Kiss/Magic and my Ox try to do. It also created a bunch of problems like Think about in-ns, ns and multi-file namespaces. #150 because (typically older) Clojure code expects to just be loaded by something and consequently in-nss to wherever its author thinks the defs should go. Core and pprint are particularly guilty of this.

• Some of the stuff like [CLJ-1074] Reader support for NaN, Infinity #125 is just low hanging fruit. Why it isn't actioned in Clojure is anyone's guess, but those changes are so minor that anyone could make them and nobody is compelled to adopt Jaunt or more accurately accept it's risk in exchange for them. Likewise [CLJ-706] Clojure deprecation support #45 (namespace and var deprecation) which supposedly Clojure will get a version of this in 1.9. We'll see, it'd be interesting to compare that implementation to this one. Add *line* #51 is in the same boat, as is CLJ-1803 #40 and [CLJ-1579] source-fn needs to read in def ns #41. There's arbitrarily much source material for this class of change sitting around in the Clojure bugtracker.

• Fn introspection #127 was actually pretty interesting and original I think. Being able to resolve uses / reaches sets is interesting in terms of understanding a codebase and is something I look forwards to using in Jaunt. Environment mutability makes it's logical partner Add compiler support for used-by information #15 really really hard.

• Implement Named in RT so the compiler can use it #145 among other changes exemplifies the problems of not being self-hosted. There's a constant question of whether some language level feature should be accessible from inside the compiler for this or that reason which leads to pushing "common" interop core functions down into RT. It'd be interesting to see if there's positives/negatives here but it's definitely an exercise in taste.

• Extend compiler with strict locals #9, Patch core for strict locals #10 I just never got to. I think that if I'd started there instead of getting hung up trying to yak shave Core it would have been easy to point at Jaunt and say hey look it's Clojure with this obvious performance win come use it. Instead I wound up with a bunch of novelty that didn't add value.

• Add clojure.queue #8 and Flesh out clojure.uuid #7 are case studies in how tempting it is to go "batteries included" because some things need RT support, when the real answer is that Clojure's core "interfaces" aren't generic enough and these things should be fully libraries. [CLJ-401] Add sequable? predicate #43 is related to this problem.

• Strict get #135 (reverted Revert "Strict get" #137) totally didn't work out. People do all sorts of stuff with get that isn't a static-typey as I'd like. This is the price you pay for trying to maintain compatibility. Also put the cramp on Should sets be contains? predicates rather than identity mappings? #151 and Refactoring defprotcol for syntax consistency with defn #155

• Improve errors from refer #142 deprecating refer and doing some really fancy head-standing in ns and friends to suggest rewrites was nice, but again not compelling and made leveraging 3rdparty libraries really noisy with false-positive rewrite suggestions. This should have been a linter feature somewhere and a hard breaking change.

• In theory Pedantic as a compiler option #2 could have been more linters as with Improve errors from refer #142, the problem is that if the linter is 3rdparty optional tooling rather than being baked in then nobody uses it consistently.

• Using lein cljfmt and astyle to try to impose sanity on the codebase totally worked and was definitely worthwhile. I wish that lein kibit --replace was more reliable because there's a lot of low-hanging syntactic fruit in terms of normalizing core that cljfmt doesn't even try to capture.

• clojure.core is a monster, with a very non-obvious definition order largely because core's first ~thousand lines is used defining fundamental operations and FFI to Java implementation details. This is important because it really comes to a head with the defn and let macros. def, defn and let as we're accustomed to them all depend on the destructuring version of let, which has a really surprisingly large transitive dependency set. While "simplifying" core seems like a good idea at first you immediately run into this tension of should core be a sprint to destructuring let so that MOST of core be written in terms of "normal" Clojure defn and let, or should all the FFI functions be written in the pre-defn-and-let subset of Clojure where first and rest are? Is doing either of these things actually an improvement? The way you solve this problem is by supporting cyclic dependencies "for real" which just doesn't work given Clojure's code loading model. This is why Ox (and Kiss and Magic) all aim for lazy loading with support for mutually recursive modules.

• clojure.core is too goddamn big. It does too much. There are a bunch of different small APIs in here that could all be their own separate namespaces.

• clojure.pprint and several other modules have no actual non-historical reason for being in core and should be removed. Except for compatibility concerns.

• clojure.*'s test coverage is actually pretty spotty. Be careful.

• doc/* needs some love. It'd be cool if doc was packaged and defs deferred their docstrings to articles in doc/ instead of having short terse-to-useless source comments.

• There's something REALLY SPOOKY going in in the load order of Clojure's test suite. I did an overhaul of the test runner which helped make the fact that the test coverage is actually pretty spotty clear and made the test output more human friendly (https://github.com/jaunt-lang/jaunt/blob/develop/src/script/run_test.clj). But it looks like between writing .class files all over everywhere (for reasons I never quite figured which may be a bug in Jaunt not Clojure) there's an ordering dependency between Clojure's test cases. If you shuffle test namespaces and try to run them in random order weird stuff happens.