Hacker News new | past | comments | ask | show | jobs | submit login

It's also the philosophy behind Clojure and why it's tied to the JVM:

https://clojure.org/about/jvm_hosted

Rich Hickey had said this is a purposeful decision and not a matter of expediency.




Unfortunately also why I haven't bothered to learn Clojure yet.

I would really like to see a Clojure that targets LLVM.


In my opinion that's not a great reason for not trying clojure (although it may be a great reason for not using clojure). Then again, if all you do is native work, then clojure is likely a bad fit in its current form.


I suppose a better phrase is, "I haven't had an interest in Clojure apart from the language itself, and dealing with the JVM and toolchain is something I find frustrating enough that I have chosen not to dive into Clojure yet."

My limited experience with the Java toolchain is that it's unnecessarily difficult to use outside of an IDE (classpaths, etc.), and using Clojure on top of it is even more difficult.

My experience is that most people who create tools for the Java ecosystem are quite content with having a bulky mess of tools, and consider IDEs (and nothing else) to be the gold-standard.

It's just something that I'd rather not contend with, even though Clojure (and Clojurescript, which suffers from the same problems) as a language sounds quite nice.


Outside of the initial installation (brew install or apt-get install or whatever you use), you really don't have to deal with the JVM ecosystem or classpaths unless you interop with Java stuff (in which case, you'd be using JVM anyway).

Leiningen (and boot) isolate you from all of that. I've been using Clojure since 09 and I don't remember the last time I even had to think about a classpath. I also use vim (and more recently, spacemacs) and not an IDE. Its not an issue in Clojure.

Although, I agree with you on the JVM in general and can see how its a reasonably assumption, even if not actually true.


Well you could look at Rhine which is Clojure inspired on LLVM. https://github.com/artagnon/rhine-ml

Personally I still love Racket and think that is the LISP of the future. Racket's number one enemy is it is fun and so everyone likes come up with their own solution. Here is one binding to LLVM from 6 years ago.

https://github.com/endobson/racket-llvm


> Personally I still love Racket and think that is the LISP of the future.

I agree. It seems quite likely that the next "hundred-year language" will either be racket itself, or live in racket's ecosystem. That, or something like red[0]

[0](http://www.red-lang.org/)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: