4 ms·
Author here. My main reason for moving away from Clojure and ClojureScript, and not towards Haskell or OCaml or even TypeScript (yet!) but rather towards modern
by _sdegutis 9y ago
Author here. My main reason for moving away from Clojure and ClojureScript, and not towards Haskell or OCaml or even TypeScript (yet!) but rather towards modern JavaScript, is because in general I've been learning to appreciate the Path of Least Resistance in software development. I wrote another aspect of this in Age of the Polyglot[1], which focuses on the friction when bridging loosely-compatible tools, but there's other friction points to the non-mainstream ecosystems, like having a stagnant or decaying community, lack of libraries, etc. A lot of active development seems to be happening in the Node world in the past 5 years, and although there's probably a ton of crap, there's also a ton of gold, and that's kind of what happens when you have a thriving community.
[1]: https://sdegutis.com/blog/2014-08-18-age-of-the-polyglot/ https://sdegutis.com/blog/2014-08-18-age-of-the-polyglot/
- yogthos 9y agoMy team has been using Clojure for about 7 years now, and we started using ClojureScript about 2 years ago. We're certainly finding it to be the path of least resistance compared to keeping up with Js. For example, we've been using Reagent for the front-end, and it's stayed the same all this time. Even as React itself keeps changing, all we have to do is update the library version, and everything just keeps working. Keeping up with the way Js world evolves is absolutely bonkers in my opinion. By the time you finish writing an app, the whole stack becomes outdates as people jump onto new hot thing. Even if you stick with something like React, the practices around it keep shifting, you now have Redux and Relay, and god knows what else people will come up with next week. Having a stable development environment is a big benefit in my book. I'm also not seeing any problems with Clojure community being stagnant or decaying. It keeps growing steadily, and the library ecosystem is quite excellent at this point. Since Clojure embraces the host platform, you always have access to native libraries as well. If a cool library gets developed in Js or Java, it's immediately available in Clojure. Node has a lot of hype, but I haven't seen anything developed on Node that's not available on the JVM. The only advantage of Node I see is that it takes less resources. Having actually developed some ClojureScript apps on top of Node, I think that it's a strictly inferior experience. Callbacks are much harder to work with than threads, and even promises and async result in much gnarlier code. Given my experience with it, I would only use Node for very simple applications.
- _sdegutis 9y ago> Keeping up with the way Js world evolves is absolutely bonkers in my opinion. By the time you finish writing an app, the whole stack becomes outdates as people jump onto new hot thing. I definitely agree which is why I haven't sunk a whole lot of time into learning any of these in particular just yet. I've stuck with vanilla JS for most front-end needs and Vue.js when I need something slightly more complex, with no build phase. > Since Clojure embraces the host platform, you always have access to native libraries as well. If a cool library gets developed in Js or Java, it's immediately available in Clojure. True but I don't see a whole lot on that front in the JVM world either. There's a few libraries that pop up here and there, but most Java work I've ever seen is done using existing tools and frameworks, unfortunately. > Node has a lot of hype, but I haven't seen anything developed on Node that's not available on the JVM. I look at it the other way around: In an incredibly short time span, NPM has pretty much covered every library that the JVM has. > The only advantage of Node I see is that it takes less resources. Having actually developed some ClojureScript apps on top of Node, I think that it's a strictly inferior experience. From a technical perspective, Node is probably inferior to JVM in most ways, yeah. But not in ways that matter significantly. Lately I've been considering social aspects to be a lot more important than technical aspects, though. I mean, Rails got popular while sitting on top of an AST-traversing Ruby interpreter. At the end of the day, as long as it's semi-usable, hype and an active community are probably more important than all the other facets of a language, at least for most web apps.
- yogthos 9y ago>true but I don't see a whole lot on that front in the JVM world either. There's a few libraries that pop up here and there, but most Java work I've ever seen is done using existing tools and frameworks, unfortunately. I still don't understand what the problem here is. Can you explain a concrete business problem you were trying to solve and found Clojure inadequate for. What was the scenario where you couldn't find a library for a specific task, or couldn't solve a problem because the language was deficient. >I look at it the other way around: In an incredibly short time span, NPM has pretty much covered every library that the JVM has. Threads is a great example of something that Java has and makes a huge difference in the developer experience. Having to chain async calls for every single thing you do is absolutely insane in my experience. Following code becomes a lot harder, debugging is a nightmare, and passing errors around has to be done explicitly in error prone fashion. >From a technical perspective, Node is probably inferior to JVM in most ways, yeah. But not in ways that matter significantly. See above. >Lately I've been considering social aspects to be a lot more important than technical aspects, though. Sure, let's talk about social aspects. Clojure community is primarily composed of very experienced developers and that directly reflects the quality of tooling and libraries available. Last I checked Clojure community is very active and it's not going anywhere. It's used at places like Amazon, Boeing, NASA, and Walmart for mission critical tasks. I certainly value quality over quantity here.