5 ms·

It’s an interesting argument. However, I’m not sure about it. Consider Rust doesn’t have a Rails per se but the ecosystem it is thriving. It seems more like an

It’s an interesting argument. However, I’m not sure about it. Consider Rust doesn’t have a Rails per se but the ecosystem it is thriving. It seems more like an indication that the Clojure community of developers is either focused on things other than the article is concerned with, or its period of popularity has waned and the libraries that do exist from that time are slowly rotting. I think about Erlang before Elixir. In its niche Erlang had a very good set of libraries, primarily centered around lower level network communication type things. But for integration with popular APIs etc. not so much. After Elixir and an influx of new people the off-the-shelf library situation got significantly better. I don’t think that’s because they were doing Rails type things necessarily but more because there was a more diverse pool of developer community, whereas the Erlang community was slowly shrinking through attrition. If you want Clojure to thrive again you’ll have to stop the attrition of its developer community. Maybe that’s by building a Rails but even your example in-article where Go is more suitable isn’t really a web type problem. What problems can Clojure solve that other languages can’t, in a way that is worth the effort for someone new to the ecosystem?

janetacarr 4y ago
I think you've answered you're own question here, in a sense. Erlang was created by Ericson for use in telecom systems. (OTP stands for Open Telecom Platform) which gives credence to the idea that Erlang didn't need a Rails. Once Elixir came along, being a bit more general purpose, people started building those things. Clojure, from the beginning, was intended to be a general purpose language, not a web language. So I think it would be fine to expect Clojure to be able to solve non-web type problems. Maybe the community has attrition, but I don't think so. The Clojurians slack seems bigger than it ever was, more companies are using Clojure than I've ever seen. edit: general not generate
- troutwine 4y ago
  Minor quibble, OTP _used_ to stand for Open Telecom Platform but that acronym was removed in the push to open-source. Ericson had hoped to sell the Open Telecom Platform to other telecoms but that didn't work out, hence the modern Erlang/OTP. Anyhow, Erlang's niche was and is fault-tolerant middleware, yeah, the kind of thing you see deep in the bowels of systems. The community built up a sizable bulk of code to support the kind of middleware you'd find in Enterprise-y type places in the early 2000s and then slowly started to fall off, leaving an ecosystem that slowly bit-rotted in much the same way you describe in your article. That, specifically, is what I'm referring to as the off-the-shelf rot problem. Perhaps I could have been more clear. I agree with the argument that Clojure was intended to be a general purpose kind of language, but I think you article also suggests that -- unless you're tied to a JVM model _and_ you refuse to use Java -- that Clojure gets out-competed by languages like Go in that kind of work. It's not clear to me how or why building a Rails kind of thing for Clojure would reverse this situation. I think, also, the size of an online community and tally of companies can be misleading. Erlang's IRC and company use was at an all-time high even while the actual pool of developers had reached its peak and was declining, slowly but surely. It's argument from analogy, sure, but what you're describing in the article for Clojure looks damn familiar from my time with Erlang, pre-Elixir.
- dustingetz 4y ago
  > Clojure, from the beginning, was intended to be a general purpose language, not a web language i don’t think that is strictly true, clojure is for “situated programs” which is basically a perfect description of cloud information systems and user interfaces. immutability and macros is not what you want for games, for example. and data science is very SQL/struct oriented, it doesn’t hit clojure’s high notes. mobile is very platform interop heavy and best done natively without adding intermediate abstraction layers. databases are written in lower level langs for performance (Datomic is not known for lightning fast queries). what’s left?
Macha 4y ago
I think the lack of a Rails or other flagship framework has arguably hurt Rust if you compare it's trajectory to that of Go. Go had Docker and Kubernetes as early flag bearers to indicate it's a "real language", while Rust has only really had the critical mass to start getting treated as one in the last two years.
- troutwine 4y ago
  Ah yeah, very fair if we’re talking “Rails” as a signifier of a big project that gives a language and ecosystem is “flavor”. For what it’s worth, I imagine Go has a broader remit than Rust even today. Go is a very good update on the pain points of Python for domains where integration with existing C libraries can be a little wonky, resource consumption isn’t a major concern. Rust puts resource consumption and fitting into existing systems projects as a first class design concern, which is great for me because that’s the kind of thing I work on, but I do admit it makes for a more challenging language to use.
- int_19h 4y ago
  They're two drastically different languages optimized for different goals. Why would they have, or even want, the same trajectory?

janetacarr 4y ago

I think you've answered you're own question here, in a sense. Erlang was created by Ericson for use in telecom systems. (OTP stands for Open Telecom Platform) which gives credence to the idea that Erlang didn't need a Rails. Once Elixir came along, being a bit more general purpose, people started building those things. Clojure, from the beginning, was intended to be a general purpose language, not a web language. So I think it would be fine to expect Clojure to be able to solve non-web type problems. Maybe the community has attrition, but I don't think so. The Clojurians slack seems bigger than it ever was, more companies are using Clojure than I've ever seen. edit: general not generate

troutwine 4y ago
Minor quibble, OTP _used_ to stand for Open Telecom Platform but that acronym was removed in the push to open-source. Ericson had hoped to sell the Open Telecom Platform to other telecoms but that didn't work out, hence the modern Erlang/OTP. Anyhow, Erlang's niche was and is fault-tolerant middleware, yeah, the kind of thing you see deep in the bowels of systems. The community built up a sizable bulk of code to support the kind of middleware you'd find in Enterprise-y type places in the early 2000s and then slowly started to fall off, leaving an ecosystem that slowly bit-rotted in much the same way you describe in your article. That, specifically, is what I'm referring to as the off-the-shelf rot problem. Perhaps I could have been more clear. I agree with the argument that Clojure was intended to be a general purpose kind of language, but I think you article also suggests that -- unless you're tied to a JVM model _and_ you refuse to use Java -- that Clojure gets out-competed by languages like Go in that kind of work. It's not clear to me how or why building a Rails kind of thing for Clojure would reverse this situation. I think, also, the size of an online community and tally of companies can be misleading. Erlang's IRC and company use was at an all-time high even while the actual pool of developers had reached its peak and was declining, slowly but surely. It's argument from analogy, sure, but what you're describing in the article for Clojure looks damn familiar from my time with Erlang, pre-Elixir.
dustingetz 4y ago
> Clojure, from the beginning, was intended to be a general purpose language, not a web language i don’t think that is strictly true, clojure is for “situated programs” which is basically a perfect description of cloud information systems and user interfaces. immutability and macros is not what you want for games, for example. and data science is very SQL/struct oriented, it doesn’t hit clojure’s high notes. mobile is very platform interop heavy and best done natively without adding intermediate abstraction layers. databases are written in lower level langs for performance (Datomic is not known for lightning fast queries). what’s left?

Macha 4y ago

I think the lack of a Rails or other flagship framework has arguably hurt Rust if you compare it's trajectory to that of Go. Go had Docker and Kubernetes as early flag bearers to indicate it's a "real language", while Rust has only really had the critical mass to start getting treated as one in the last two years.

troutwine 4y ago
Ah yeah, very fair if we’re talking “Rails” as a signifier of a big project that gives a language and ecosystem is “flavor”. For what it’s worth, I imagine Go has a broader remit than Rust even today. Go is a very good update on the pain points of Python for domains where integration with existing C libraries can be a little wonky, resource consumption isn’t a major concern. Rust puts resource consumption and fitting into existing systems projects as a first class design concern, which is great for me because that’s the kind of thing I work on, but I do admit it makes for a more challenging language to use.
int_19h 4y ago
They're two drastically different languages optimized for different goals. Why would they have, or even want, the same trajectory?