> It gives Clojure another usecase: a "production-ready prototype" language where the resulting "prototype" can last for eight years [...] until it gets rewritten to something else when all the hard questions are answered, and most experimentation/wandering is over.
That general story, first heard from Paul Graham, about projects starting with Lisp and being successful that way, before eventually being rewritten, works for me.
I've been hoping at least a couple college startups would be inspired by this to use Racket initially, but if they have, I haven't heard of it. (I speculate that the current FAANG feeder emphasis among CS students hasn't helped. Who has time to play with a Lisp, when the now-all-important whiteboard interviews won't use it.)
> Obviously, much more people will be able to consider contributing when it's in Java.
If you have a company, and you want to hire Lisp people (whether it's Clojure, CL, or Scheme/Racket), I think you can probably hire people, because Lisp people like getting paid to use Lisp.
If you're looking for unpaid/volunteer contributions to an open source project, there's all sorts of things that affect that, and it's not unusual to get little-to-no contributions.
This is correct, it was “Storm ditches Clojure in favor for Java”.
It is a success story for Clojure, but this move is a big negative feedback for the language. A team starting out on an open-source project will be mighty reluctant to start it with Clojure; because it might get rewritten not so much into the future. That is not good news for Clojure
As for switching to Java, that makes perfect sense to me if that is what the contributors prefer. If you're going to make a big rewrite, you might as well change the language to one you prefer when you have the opportunity.
As someone who spends 100% of dev time in Clojure, I'm quite happy to see this development. Dipping into Java isn't uncommon for optimizations in Clojure, so this is like someone taking the time to do a massive under-the-hood optimization from the point of view of a Clojure user. I doubt it changes the project's status much in the Clojure community. Perhaps it'll even see an uptake in use.
What it doesn't say much about is Java vs. Clojure in my opinion. Different contributors, with different amounts of pertinent knowledge, and years apart. I'm not sure how you would control for those variables in a comparison. It should be read more as, "we put in a heck of an effort to make this thing faster and more useful", and kudos for that.
So, you can say that Clojure among everything else is my IDE to write Java code. Is that a bad suit for a language? Depends on your perspective, but I personally am very happy that I have Clojure by my side.
It’s quite a mature language so I’m not sure that bodes we’ll for its prospects this late in the game.
I think it speaks of something.
(Personally, I think the change is rather evidence of the primary drivers behind Storm development in 2019, and... that's not a good thing.)
I saw Clojure become popular long before it was ready for the limelight: it definitely wasn’t pragmatism driving it. It was a fetish for syntax and paradigm.
Begs the question, why not just write it in Java? Then at least its more likely to be a refactor down the road rather than a rewrite.
I think clojure ought to be a production ready language that scales well. That’s what it was designed to be. However lisp seems to dichotomise devs into those that get it and those that don’t and thus alienates many would be team members.
I am drawn to the idea of scalable languages or languages with zero friction for interop.
This thread on Pallene is interesting https://news.ycombinator.com/item?id=18038619
I also consider this a success story for Clojure. It gives Clojure another usecase: a "production-ready prototype" language where the resulting "prototype" can last for eight years and benefit thousands of developers until it gets rewritten to something else when all the hard questions are answered, and most experimentation/wandering is over.