re: Will Java Trend Towards Obscurity? VIEW POST

FULL DISCUSSION
 

I believe that Java, as a platform, will never die. The JVM and its ecosystem of incredibly high-quality libraries, coupled with its deep roots in large-scale enterprise environments, makes it a worthy platform to develop for and will always continue to live on.

However, I do believe Java as a language will be increasingly replaced by Kotlin. Other JVM languages (Scala, Groovy, Clojure) might have tried to replace Java, but they never really delivered on that promise. They all did wildly different things using Java as a backbone, but simply aren't comfortable to devs used to doing things "the Java way". Scala brought pure functional programming. Groovy made it dynamic. But Kotlin is the first that was actually created to just be a better Java, and by-and-large if you're comfortable writing Java8-style code you'll pick up Kotlin very quickly and fall in love.

But a major part of the success of Kotlin is its perfect interop with Java. Kotlin is great because under-the-hood, it is just Java. There is nothing fundamentally different going on with Kotlin than plain-ol' Java. Both Scala and Groovy have their own runtimes which run on the JVM but aren't entirely compatible with Java. Kotlin just compiles to the exact same thing that Java does, which is a huge advantage for incremental migration, especially in large, slow-moving enterprises.

So, again, Java isn't going anywhere. But I do think it's moving the same direction that C has, being the language that underpins all others. And to that point, Javascript is moving in this same direction as well. It is a sign of maturity of the language, that it has gone from being a language used directly, to being part of the fabric for the next level of technology.

 

This is a good summary. I'd add to this that Kotlin actually really strives (to me it seems that way at least) to get out of the JVM's headlock. Kotlin Native (LLVM compiled) seems to point exactly in that direction.

 

I don't think it's trying to get out of the JVM headlock at all. The Jetbrains team is perfectly happy having Kotlin remain a better Java. I think they just saw a great opportunity to increase popularity of Kotlin by making it possible to reuse code across multiple projects using different tech stacks.

In particular, the adoption for Android made it natural to want to use the same code for iOS, and so Kotlin/Native was born. Likewise, using Kotlin on the server made it natural to want to use the same code on Javascript clients, and so we got Kotlin/JS.

But on both cases, I think the branching into other platforms is driven very strongly by its deep ties to the Java platform, and that will continue to be its bread-and-butter.

 

I think you're spot on with this. The JVM and Java ecosystem are going to around for a LONG time, especially in the enterprise. I doubt we'll see many startups using Java out of the gate, but I can see Kotlin being a nice bridge into JVM-land when you need that kind of power/flexibility.

 

The interop is good, but it’s not perfect. It’s especially bad when reflection is involved (see what happens when you deserialize data class Data(val SomeKey:String) with jackson.)

Other problems revolve around functions named to and in and is being unusable in some situations.

Not to mention that one gremlin dsl class named __!

Kotlin is nice, but IMO the interop is less nice than Clojure’s interop or even the F#/C# interop

 

I missed the point of how the interop could be better in Clojure. For one, you can't write serious Clojure for Android, which is a major use case for Java nowadays. What I really disliked when using Clojure interop is that I ended up writing "clunky" Clojure just to fit into Java's way of doing things. Just having to use an object-oriented call from a Lisp syntax feels really messy.

IMO Kotlin has the best interop story so far for everyday use cases.

True, but I almost never had to just "cast and hope" with clojure calling java code. When it comes to "serious" java (read: "enterprise class" with as much derision as possible) reflection tends to become involved and Kotlin's type system is quite a bit more conservative.

I agree about the awkwardness of

(let [b (SomeBean. )]
  (.setA b a-value)
  (.setB b b-value)
  b)

I tended to hide those away under the rug.

That was spot on. I love functional programming and Clojure got me for a while until I had to do exactly that.

In my wildest dreams I see Lisp becomes a mainstream language people use to teach and learn programming. I'm still writing Scheme on the side sometimes.

Tangentially, looking at my let, I saw a familiar construct staring back at me:

val b = SomeBean().apply {
  a = aValue
  b = bValue
}

LOL. Actually Kotlin stole quite a lot from Scala, which is a functional language inspired by Lisp. So your observation wasn't wrong.

code of conduct - report abuse