Hacker News new | ask | show | jobs
by pjmlp 2050 days ago
On the JVM, I think Scala won't have any major issues it is just another guest language and isn't used to sell InteliJ licenses.

Kotlin is chaining itself to Android, it will rule there thanks to Google's sponsorship, on everything else it is just yet another language to chose from with a weaker eco-system, used to sell InteliJ licenses.

2 comments

> used to sell InteliJ licenses

Though IntelliJ has amazing features for Java/Kotlin: it comes with a free version that packs most of 'm. I think saying it's all to sell licenses is a disingenious, lots of longstanding Java pain points get addressed by Kotlin in a really nice way. It has a really strong webdev ecosys building up, and comes with a rather interesting feature set as language itself. I'd say its good "typed Ruby" (OO at the core, FP where it makes sense, very expressive, dont type too much).

Scala's issues on the other hand stem, I think, from it being multi-paradigm. Where Kotlin is OO-core with FP where it makes sense, Scala is both OO and FP at the same time which makes it messy.

Frege explored being full FP on the JVM, but looking at the repo[0] it did not get much traction.

[0]: https://github.com/Frege/frege

Not at all, JetBrains are the first ones to admit it, also why they decided to stop contributing to Eclipse and merging the Kotlin plugin into the InteliJ source tree.

> Kotlin support for VSCode or other IDEs is not on the roadmap for the Kotlin team. Community initiatives in this respect are welcome.

-- https://kotlinlang.org/roadmap.html

> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.

-- https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...

Thanks for your reply. You have a point, but there is to me still a difference between a "scratch-itch language created and a good biz model on top", and a "biz model that required a new language".

There is some legal stuff going on as well: Java was being monetized by Oracle and Google needed a way out. This helps Kotlin a lot imho. When then free-Java case totally lost, Google allows all to move to Kotlin and IntelliJ has the code translator tool (and will prolly get bought by Google at some point).

Google screwed Sun and had their opportunity to buy it.

The Java ecosystem has dozens of JVM implementations. None of them have ever had a problem with either Sun or Oracle.

Only Microsoft with their J++, and Google with their actions fragmenting the ecosystem for Java developers.

Microsoft learned their lesson and are now a OpenJDK contributor.

Time will come for Google as well.

Switching to Kotlin doesn't remove the dependency on the Java world, unless they plan to rewrite everything in Kotlin/Native.

Kotlin has significant support from the largest Java ecosystem: Spring. In my experience it's also much more compatible with Java/JVM libraries. In Scala that's perfectly possible but leads to very un-idiomatic code, in Kotlin you barely notice.
> In my experience it's also much more compatible with Java/JVM libraries. In Scala that's perfectly possible but leads to very un-idiomatic code, in Kotlin you barely notice.

I think that's actually reversing as Kotlin and Java diverge. E.g. interop with Java Optionals is very easy in Scala (and they obviously correspond directly to Scala Options) whereas it's harder to make them fit with Kotlin nullable types. And Kotlin's "suspend functions" are unlike anything else and mean you have to understand a concept of "inline" that changes the semantics of the function it applies to; e.g. calling a Java function that takes a callback from an async function is straightforward in Scala, but not so much in Kotlin.

Scala has an issue with the concept of "idiomatic code". I'd say when it comes to "idiomatic code", Go and Scala are at the opposite sides of the spectrum.
Spring supports everything that helps their bottom line.

Where are the Groovy, Scala, Clojure support nowadays?

Groovy is still alive within the context of Grails (which is basically a very nice wrapper around Spring) and Micronaut (which is a direct competitor to Spring). Micronaut officially supports Java and Kotlin as well.
I was referring to the way Spring used to sell that they supported those languages, just like they do with Kotlin now.