4 ms·

Clojure is the language I'm most productive in. At the beginning of the year I quit my job to write a book about Clojure [1], do some consulting, and build a d

Clojure is the language I'm most productive in. At the beginning of the year I quit my job to write a book about Clojure [1], do some consulting, and build a developer tool I've been talking about for a few years. For the tool, I'm using a client/server model, and on the client side latency is a huge concern, so I'm using Java. Java is basically assembler for the JVM, and has extremely predictable performance characteristics. Where performance is a non-issue, or I only care about throughput, I'm using Clojure, because it's much more expressive. I think the tradeoffs of the two languages are very complementary, but also much less extreme than, say, Ruby and C. I find the inertia of the core implementation of the language annoying, even if it's not a huge problem for most applications. Clojure's immutable data structures were world-class when the language was first released ten years ago, but there have been a number of papers which detail improved approaches since then. I've implemented most or all of them [2], but the chance of getting these back into Clojure is effectively nil. That doesn't affect me (I can just use my own data structures), but it does give me some concern as to where the language will be after another ten years. [1] http://elementsofclojure.com/ http://elementsofclojure.com/ [2] https://github.com/lacuna/bifurcan https://github.com/lacuna/bifurcan

christophilus 9y ago
A. Thanks for the response. B. Interesting. I saw a recent article on high-performance immutable data-structures[1], and wondered what the odds of Clojure implementing them might be. Sounds like you think the odds are minuscule. C. I've heard great things about your book, and it is on my reading list! Thanks for writing it. D. Given your hesitancy about the future of Clojure, what is your opinion of a more future-proof stack that has similar properties to Clojure (functional, simple, data-oriented, etc)? I can't think of many. ReasonML is interesting, but immature and definitely more complex than Clojure. Elixir seems to be promising, but I don't like the language, and I don't like being constrained to doing everything the BEAM way-- JVM is nice for high-perf computing when needed... Anyway, I'd appreciate your thoughts! [1] https://news.ycombinator.com/item?id=15005569 https://news.ycombinator.com/item?id=15005569
- prospero 9y ago
  The chance of my implementation being folded into Clojure, as opposed to whatever Rich writes himself, is definitely tiny. But there's no telling when he might get around to it, so the best way to stay sane is to assume it will never happen. Clojure occupies a really nice local maximum, and I don't think any other language is trying to compete for that niche. Since Clojure is just a Java library, it's relatively easy for you to extend or replace any part of it, so I don't think the future is a concern for anyone who enjoys the language and is motivated to use it. Rather, I worry about the growth of the community, since that's largely predicated on the out-of-the-box experience. As an author and consultant who is focused on Clojure, that affects me far more than a company which builds its product using Clojure (assuming you're willing to hire people with an interest in FP and teach them the rest in their first month). I don't claim expertise in how to grow a community around a language, but it seems to be at best a part-time job for the people at Cognitect, which is not ideal.
  - reilly3000 9y ago
    I am seeing pretty healthy CLJS adoption, especially as NPM access becomes easier and easier. The things that are happening on the client side seem to be out front of the rest of the industry fairly consistently over the past few years. I think that bodes really well for the Clojure community overall.
- hnzix 9y ago
  > Elixir seems to be promising, but I don't like the language Here is an interesting /r/clojure thread about Elixir vs Clojure: https://www.reddit.com/r/Clojure/comments/6wn6t5/new_clojurians_ask_anything/dm9fox4/ https://www.reddit.com/r/Clojure/comments/6wn6t5/new_clojuri...
- mercer 9y ago
  What are your main issues with Elixir's syntax?
tensor 9y ago
From recent discussions on the CHAMP stuff I was under the impression that once clojure equality semantics were matched the performance improvements were fairly minimal. This is why there isn't more urgency around updating the core data structures. Is that not how you see it?
- prospero 9y ago
  You probably saw my response in that thread, where I said that the dramatic performance improvements in lookup speed reported by the CHAMP paper were mostly because they were comparing apples to oranges. However, Clojure's equality semantics only really help in some niche situations (where you want to be able to use ints, floats, and bignums interchangeably, mostly), so making the equality semantics configurable would be a huge win for all sorts of applications. Also, lookup is not the only performance win that CHAMP offers: https://github.com/lacuna/bifurcan/blob/master/doc/benchmarks.md https://github.com/lacuna/bifurcan/blob/master/doc/benchmark.... One thing the approach makes possible, which wasn't explored in the paper, is the ability to do union/difference/intersection operations structurally, rather than just iterating over each element in the set. None of these improvements are so overwhelming that they take priority over everything else. Clojure's data structures are still really well made. Given how data-focused the language is, however, I think these improvements are more compelling than everything that's been added to the language in the last five years other than `clojure.spec`.

christophilus 9y ago

A. Thanks for the response. B. Interesting. I saw a recent article on high-performance immutable data-structures[1], and wondered what the odds of Clojure implementing them might be. Sounds like you think the odds are minuscule. C. I've heard great things about your book, and it is on my reading list! Thanks for writing it. D. Given your hesitancy about the future of Clojure, what is your opinion of a more future-proof stack that has similar properties to Clojure (functional, simple, data-oriented, etc)? I can't think of many. ReasonML is interesting, but immature and definitely more complex than Clojure. Elixir seems to be promising, but I don't like the language, and I don't like being constrained to doing everything the BEAM way-- JVM is nice for high-perf computing when needed... Anyway, I'd appreciate your thoughts! [1] https://news.ycombinator.com/item?id=15005569 https://news.ycombinator.com/item?id=15005569

prospero 9y ago
The chance of my implementation being folded into Clojure, as opposed to whatever Rich writes himself, is definitely tiny. But there's no telling when he might get around to it, so the best way to stay sane is to assume it will never happen. Clojure occupies a really nice local maximum, and I don't think any other language is trying to compete for that niche. Since Clojure is just a Java library, it's relatively easy for you to extend or replace any part of it, so I don't think the future is a concern for anyone who enjoys the language and is motivated to use it. Rather, I worry about the growth of the community, since that's largely predicated on the out-of-the-box experience. As an author and consultant who is focused on Clojure, that affects me far more than a company which builds its product using Clojure (assuming you're willing to hire people with an interest in FP and teach them the rest in their first month). I don't claim expertise in how to grow a community around a language, but it seems to be at best a part-time job for the people at Cognitect, which is not ideal.
- reilly3000 9y ago
  I am seeing pretty healthy CLJS adoption, especially as NPM access becomes easier and easier. The things that are happening on the client side seem to be out front of the rest of the industry fairly consistently over the past few years. I think that bodes really well for the Clojure community overall.
hnzix 9y ago
> Elixir seems to be promising, but I don't like the language Here is an interesting /r/clojure thread about Elixir vs Clojure: https://www.reddit.com/r/Clojure/comments/6wn6t5/new_clojurians_ask_anything/dm9fox4/ https://www.reddit.com/r/Clojure/comments/6wn6t5/new_clojuri...
mercer 9y ago
What are your main issues with Elixir's syntax?

tensor 9y ago

From recent discussions on the CHAMP stuff I was under the impression that once clojure equality semantics were matched the performance improvements were fairly minimal. This is why there isn't more urgency around updating the core data structures. Is that not how you see it?

prospero 9y ago
You probably saw my response in that thread, where I said that the dramatic performance improvements in lookup speed reported by the CHAMP paper were mostly because they were comparing apples to oranges. However, Clojure's equality semantics only really help in some niche situations (where you want to be able to use ints, floats, and bignums interchangeably, mostly), so making the equality semantics configurable would be a huge win for all sorts of applications. Also, lookup is not the only performance win that CHAMP offers: https://github.com/lacuna/bifurcan/blob/master/doc/benchmarks.md https://github.com/lacuna/bifurcan/blob/master/doc/benchmark.... One thing the approach makes possible, which wasn't explored in the paper, is the ability to do union/difference/intersection operations structurally, rather than just iterating over each element in the set. None of these improvements are so overwhelming that they take priority over everything else. Clojure's data structures are still really well made. Given how data-focused the language is, however, I think these improvements are more compelling than everything that's been added to the language in the last five years other than `clojure.spec`.