I noticed that there are a few 1.10 alphas out: https://clojure.org/community/devchangelog
Anybody knows what is the roadmap to 1.10 - what is the focus of the new version?
Clojure does not have a public roadmap. You’ll hear about it when it’s there.
This is different than a lot of other open source languages, and it’s something many of us regret, but it’s a deliberate choice by the authors not to run Clojure as a community project, and that’s a choice we have to respect.
3 Likes
Ok - but maybe there is informal hearsay. Nobody else is just curious?
1 Like
I’ve heard it said that even people pretty close to Rich only find out about new stuff after the fact. The best you can do is watch the repo, keep an eye on the mailing list, or maybe talk to Cognitect people in person when you get the chance.
And speculate. Nothing wrong with that 
How about we turn this into some release notes fanfic? What would clojure 1.10 look like in your wildest dreams?
4 Likes
If there are any themes or big features coming, this page tends to list them: https://dev.clojure.org/display/design/Release.Next+Planning
But there’s nothing there right now so, as @plexus says, we’re currently in for whatever Rich has in mind.
The structured prepl is interesting. Given the deps and CLI stuff in 1.9, I think we’re leading up to some sort of debugging or testing tooling bump “out-of-the-box” but I can’t currently imagine what that’s going to look like.
We’ve run alphas and betas in production ever since 1.3.0 back in 2011 so, as far as I’m concerned, Clojure just goes through a continual and very careful series of enhancements. The “releases” have never been important to us since we’ve been leveraging those new features since they first appeared in an alpha.
We haven’t yet figured out how to leverage prepl so we haven’t jumped to an alpha yet for 1.10.0 but we’ll probably do that as a matter of course anyway soon regardless.
1 Like
I have no special knowledge or inside information, but (in the spirit of wild speculation), I think that if you look back at the feature list for the last few releases, we seem to be entering a new era of Clojure development focused around tooling.
Clojure took until around v1.4 or v1.5 to simply stabilize as a language and platform. Then, starting with v1.5 and the introduction of Reducers, followed by Transducers in v1.6, Rich seemed to shift his focus to interesting language-level inventions he could introduce that would be unique (or mostly unique) to Clojure. Finally, with the socket REPL, spec, clj, and now the pREPL, we seem to be getting features that should help out tool makers.
It is a bit of a shame that the development process is not more open, given that there already exists quite the tool ecosystem for Clojure, and I’m sure many of the authors of these packages would gladly provide feedback and/or suggestions but, as @plexus correctly states, this is the deal with the devil Rich that we have made in exchange for, arguably, one of the nicest, most productive languages currently available.
2 Likes
We don’t have a roadmap yet for 1.10. Current things that we are working on are:
- a new tool from Rich that is driving the prepl work in 1.10 (coming soon I hope!)
- a spec update for more programmable friendly specs. Ideally I’m hoping that in the 1.10 timeframe we will drive spec through to “final” and undo that bit of alpha-ness. Probably more work on core specs too.
- more work on tools.deps.alpha and the clojure tools (clj). In particular, I’m hoping to push through Windows support and some of the Maven and git authentication additions that have been proposed to increase its reach and utility. Hoping to get this out of alpha nearish term too - the apis have largely settled down at this point.
- a project I’m working on related to startup time
Notably, 1-3 are not dependent on a Clojure 1.10 final release and all of these are all likely to be available for use within the next few months. So “1.10.0” might be a ways out but we will be delivering new stuff regularly.
20 Likes
I think rather than focus on features, it’s more helpful to focus on problems to understand Clojure’s trajectory (I will undoubtedly use more and poorer words than Rich would for all of these):
- Composable, reusable data transformation - reducers, transducers, core.async
- Automatic parallelism - fork/join parallel stuff, reducers
- Portability - reader conditionals, cljc
- REPL tooling - socket repl, Throwable->map, clj, prepl
- Agile Clojure program building - core relying on libs, tools.deps.alpha, clj, git deps
- Describable data - data readers, edn, transit, spec, namespace map syntax, namespace map destructuring
- “Language of the system” - core.async, transit, var serialization
- Performance - reducibles, direct linking, lazy vars (future)
- Getting started - spec (incomplete), clj, git deps, clojure.org site, api doc infrastructure
These are all big arcs that cross many releases. Attention may phase in and out on any one of these at a time but they are all problems of enduring interest. Many of these only lightly touch “the core language” or even the core library, and that’s by intent. In the words of Rich, Clojure is a small language and intends to remain so. If you want to envision where Clojure is going, think about new steps on those arcs, which are largely not “new language” and may not even be “in Clojure” but around it in libs.
We’d love to hear feedback on the tooling stuff. I have taken and acted on a lot of feedback already for clj and plenty of stuff is queued up.
18 Likes
Regarding feedback on the tooling I think it’s a great step forward. We have a fairly complex setup (here’s @plexus describing some of our issues we ran into).
It now looks like we’ll be able to migrate to tools.deps, test-runner, cljs.main and pack. We’ll keep a project.clj around to install datomic using lein until there’s a built-in solution for authentication (see TDEPS-9) but I think it’s looking very promising. Will keep you posted about our progress. Thanks a lot for your great work on it @alexmiller!
2 Likes
a project I’m working on related to startup time
Are you at liberty to provide details? Just to satisfy my burning curiosity.
1 Like
Well, @alexmiller may not answer directly, but we can speculate. There’s a whole document written on the topic: https://dev.clojure.org/display/design/Improving+Clojure+Start+Time There are references to patches and branches that are already in the repo or on jira.
A big win would be lazy-loading vars (in the fastload branch). In a “real world” application, they’ve measured 17% improvements in startup times, just by avoiding work until later.
The tradeoffs with lazy vars are 1) they only really help you when you have AOT compiled and that does not cover typical dev usage and 2) they make all subsequent use of a var slower (as you have added a guard to every invocation). So, while lazy vars are potentially useful for reducing production startup times they also make production usage slightly slower. It’s unclear whether this combination of tradeoffs actually affects the cases people care about (in the current state - invokedynamic could potentially eliminate #2).
1 Like
Thanks for the info, Alex! One question – once spec is final (for some value of “final”) will clojure.spec remain a fully separate library that has to be added as a dependency, or will it become more closely integrated into the standard library like eg clojure.core.async? I have vague memories that the intention was closer integration, back when spec was first separated out, but that might have changed, or I might be completely misremembering 
Undetermined yet, but I think the most likely thing that will happen when spec is final is that it will continue to be a separate library depended on but not included in the main clojure artifact.
core.async is a different case in that it depends on clojure, whereas clojure depends on spec.alpha.
2 Likes
Thanks, Alex! Makes sense.
In case I haven’t said it before, your patient willingness to help people understand Clojure-related issues with clear, insightful answers is an enormous gift to the community, and I find I have reason to be grateful for it pretty frequently. Thank you so much for the work you do! (and that’s not even mentioning the work you do on the language itself – I have no idea how you manage to do it all).
5 Likes
Yeah, just powershell port of clj for Windows (almost done!).
5 Likes
I’m very happy to see that auto concurrency and parallelism are a concern, I use Clojure mostly for intensive data processing tasks and the fact I’m able to easily (at least it is much easier to me than in other languages) parallelize most of the work is one of the major killer features.