Clojure's "killer feature" for me is the by-default persistent data structures. Are there any other functional languages out there with similar features? Lisp or otherwise.
[deleted]
Is Clojure dying, and what has Ruby got to do with it?
61–70 of 261 posts
Re: Is Clojure dying, and what has Ruby got to do with it?
#62Going further, it seems like the whole category of alternative languages hit a peak about three years ago, and interest has been dwindling since. It's like coders got their fix of "new ways of thinking about code", and now have gone back to whatever they feel most productive in. Moreover, the buzziest alt languages now (Elixir, Go, Kotlin) seem to be much closer to existing mainstream languages than the buzzy ones of…
I think that's more an indication of _just how much the needle has been moved_. 5 years ago mainstream was something like PHP or Java 6.
Err, maybe 15 years ago, sure.
5 years ago it was the same applicants as today, only minus Go and Rust. Python and Ruby were strong in the dynamic region, Perl 6 was still an inside joke, C++ still dominated game development, Javascript was still the mainstay of web development, and so forth.
Re: Is Clojure dying, and what has Ruby got to do with it?
#63clojure's killer app, datomic, is closed source in my opinion, this is a key reason, why clojure is not thriving i can't think of any (problem) domain, where clojure have a framework or library, than is significantly better than most other frameworks or libraries if you are not number 1 at anything, it is hard to thrive
I use Datomic everyday. While it's certainly a stunning piece of technology and you could pry it from my cold dead hands, I don't think it has that much bearing on the growth of the Clojure community.
Sure, but that's the point: if Datomic is "the best thing Clojure's got" as far as killer-apps go—and it's not really that important to the community—then Clojure doesn't really have a killer app.
A killer app is something that looks like Rails does in Ruby, or Phoenix does in Elixir: a thing where 50%-or-more of the people learning the language are only learning it in the context of using that one framework, and so often get confused as to what's a feature of the language vs. a feature of the framework.
Which is, y'know, an awful annoyance for the people who use the language for other things—but boy does it pull people in.
Re: Is Clojure dying, and what has Ruby got to do with it?
#64I think Clojurescript might be the thing. With advances in the Google Closure compiler, it's getting better and better. And the front end developer tools and libraries in Clojurescript are _the best_ out there. The holy grail for javascript exists in Clojurescript. Until then I'll keep making my Javascript env look like Clojurescript. With janky react devcards, Immutable.js, and react-redux.
Agreed. I suspect one current thing hurting adoption from the JS community is the very heavy JVM based tooling. With the Google Closure compiler now running on top of JS, there would seem to be a path for the CLJS(not clj) tooling to become more JS ecosystem friendly. For the JS developers out there, is this something that's of interest? Or is the existing tooling(lein) good enough? What would be your ideal tooling s…
I like leiningen. The stability is something I never saw anywhere. You have plugins without updates for like 2 years and working like it was updated recently. Although it is becoming less common for clojure/script projects to be unmaintained.
Re: Is Clojure dying, and what has Ruby got to do with it?
#65Is Ruby supposed to be an example of "not dying" language? Because it has certainly passed its glory days as well. Also Common Lisp is better in every way ;) There's even a JVM implementation (ABCL) for people who like that sort of stuff.
> Is Ruby supposed to be an example of "not dying" language? Because it has certainly passed its glory days as well.
It may have past the (or a local) hype peak, but it seems to be doing just fine. Not being the edgy flavor of the month isn't the same as dying.
Re: Is Clojure dying, and what has Ruby got to do with it?
#66I'm still left with the question of "why all the parenthesis?" While it might sound silly and reductionist, it is ostensibly the single hurdle I could never overcome when it came to lisp languages. The majority resides with the fact that it could work without them, so I see it as an ancient artifact.
Contrast, for a moment:
var x = fib(a, b);
(let x (fib a b))
Let's try something a bit harder.
function(a, b) {
return a * b;
}(6, 4);
((fn (a b)
(* a b)
) 6 4)
Yes, "why all the [symbols]" indeed.
Re: Is Clojure dying, and what has Ruby got to do with it?
#67I think Clojure's mistake is to sell itself as a JVM language. Sure, there are lots of people who love or need to use the JVM, but for everyone else it is a downside. There is already one language that is the queen of JVM, Java. Every other language is faded to become a second class citizen.
Re: Is Clojure dying, and what has Ruby got to do with it?
#68Earlier quoted context omitted.
I use Datomic everyday. While it's certainly a stunning piece of technology and you could pry it from my cold dead hands, I don't think it has that much bearing on the growth of the Clojure community.
Sure, but that's the point: if Datomic is "the best thing Clojure's got" as far as killer-apps go—and it's not really that important to the community—then Clojure doesn't really have a killer app. A killer app is something that looks like Rails does in Ruby, or Phoenix does in Elixir: a thing where 50%-or-more of the people learning the language are only learning it in the context of using that one framework, and so…
Clojure, and lisp in general, tends to avoid the "framework" way of thinking prevalent among object-oriented languages. It's therefore no surprise that something like Rails hasn't taken off.
There are, however, libraries and patterns which are very common, ring for example.
Re: Is Clojure dying, and what has Ruby got to do with it?
#69For me, there are a number of ideas in Clojure that I think are wonderful. I just really hate reading and writing lisp code. I can't think of a syntax I like less, unfortunately, even including junk like Visual Basic.
Re: Is Clojure dying, and what has Ruby got to do with it?
#70I do wonder how much the purchase of Sun (Java) by Oracle and/or the slow down in Java advancement has affected those languages that a primarily hosted on the JVM.
I always thought the Java tie-in was a double-edged sword. For some potential Clojure users, in addition to learning the language they were interested in, they'd also have to half-learn a language (and its tooling) that they probably weren't interested in. I guess in the US there is/was an assumption that everyone coming out of the computing education system is already experienced with Java.
I feel like Clojure is more of a language that just happens to exist in the same package ecosystem as Java, and which offers a good syntax for fluently calling into the APIs those packages offer. Like Elixir with Erlang, or Rust with C.
You don't really need to know Java to write Clojure, though you do need to know things about the JVM and about the particular (Java) types that the JVM's reflection and concurrency primitives are built on. Just like Elixir still requires you to understand BEAM and OTP primitives, or Rust still requires you to understand the "C Abstract Machine" and (usually) POSIX primitives.
In at least the Clojure and Elixir cases, I don't think the runtime was chosen because anyone was expected to be familiar with the relevant abstract/virtual machine; they were chosen because BEAM and the JVM are just well-engineered VMs that have decades of research and bug-fixing and stress-testing put into them, and it's a "free win" for your language's production-readiness if you build on such a runtime. Interoperability with existing code in that ecosystem is also nice, but secondary; people using your language want to use your language, after all; if they wanted the best interoperability with Java, they'd just use Java.
(In the Rust case, [zero-overhead] interoperability with C code really was the paramount concern; but still, that's interoperability with existing C code, not the expectation that anyone would want to "take advantage of C" by writing hybrid Rust/C projects. If you're using Rust, you probably want to be writing Rust, not C.)