Hacker News Reader

Comment by badsavage | Hacker News Reader

Clojure is a different language. Being "fully compatible" with (more similar to) Java was never a goal.

This is why guest languages tend to fade away, as the platform evolves and the platform system languages adopt the features that made those guest languages appear in first place.

That is true for guest languages designed to overcome specific issues in a given language (think CoffeeScript vs. JavaScript in 2012 and then in 2019). But I don't think it really applies to Java vs. Clojure, which both pretty much force a specific (different) programming paradigms and have completely different design.

True but you need to access the libraries in Java. That is a little bit hard in some cases.

I find that I tend to do very little interop nowadays, and it predominantly happens at the edges with things like database drivers, and so on.

Yes most of the things just work.

Clojure accepts multiple hosts and is simple enough to port to new ones – a hugely underappreciated reason that Clojure is permanent

Just like many Lisp and Scheme implementations that came before it.

I'm looking at the docs -- is there a guide for targeting new host langs? As a starting point, what is the minimum "core" language that needs to be defined in the host lang so that the rest of the system can be bootstrapped by Clojure libs? (Clojure.core doesn't seem to be the answer -- there seem to be plenty of non-core/prim functions defined there.

Also, are Clojure libs (either automatically or via attribute on the package) flagged as "pure" (Clojure-only) vs. needing imports from a specific host lang?

Yes, the special forms.

https://clojure.org/reference/special_forms

Clojure follows the Lisp convention of providing platform specific behaviour via the reader.

https://clojure.org/guides/reader_conditionals

Not sure I follow -- there are certainly many primitives that must be defined by the host to bootstrap that are not special forms -- starting with list, cons/conj...

I doubt there’s a guide anywhere: it’s far from a trivial undertaking. If you want to look at the Java code that builds all the primitives, see the Clojure/Lang folder:

https://github.com/clojure/clojure/tree/master/src/jvm/cloju...

Part of what makes it Clojure instead of just a Java-based lisp are the persistent data structures that allow for efficient immutability, and the seq interface for working with collections smoothly. There’s a big (scary, to my eyes) set of classes that underlies all of the convenience. Thankfully it’s very stable so I don’t have to think about it.

Unless they follow up and keep up with the host platform. This is the biggest pain point with Clojure for me, the java interop has some limitations that we could not come by.

Kotlin seems promising (because of android).

Not really.

Kotlin already has an impedance mismatch with the JVM, because like all guest languages they have come up with their own ideas, which don't follow how the platform ended up implementing them.

Examples are sequences vs streams, lambdas vs SAM types, default interface methods, co-routines vs fibers, inline classes vs records, reflection.

Only first class support on JetBrains products, while many Java shops are still Eclipse, NetBeans and Oracle Studio users.

Additionally, since they want to stretch outside the JVM, there are semantic restrictions if the code is also supposed to be compiled by Kotlin/Native.

Kotlin has indeed a future on Android, given that Google is unwilling to move their support beyond the Android Java flavour (aka Google's own J++) and with #KotlinFirst, Android has become the KVM.

So, on Android I do agree that Kotlin has a bright future, however in what concerns the JVM I forsee an adoption cycle like every other JVM guest language.

Reply on news.ycombinator.com