Kotlin is officially supported by Android which is huge, and the fact that IntelliJ dog foods their own product into their most important product also gives a degree of security about its future.

Another huge advantage Kotlin has over Scala is tooling, which is basically all thanks to an IDE company creating the language. Tooling will never fall behind because they are in the business of selling tools.

Yes because Google is known for its long term commitment to initiatives.

As far as JetBrains, I am big fan, I have a license for R# that I gladly pay for, but JetBrains is just one company whose core set of products are rapidly being encroached upon by free alternatives.

I see lots of shiny new free editors, but IDEs, especially with deep semantic models and refactorings, are a rare breed.

Outside of Java, jetbrains doesn't have much or anything to offer against vscode, hence the GP's comment.

Jetbrains is even lagging behind, look at vscode remote capabilities which is way ahead jetbrains remote features.

For scala, Jetbrain IDE is far better than VsCode + langage server protocol

For the time being...

Eclipse, Netbeans, Visual Studio, QtCreator look quite nice to me.

Best of all, I can use Java in any Java IDE.

having used the first three extensively , i’d say intellij is miles beyond them.

Indeed it wins hands down making my laptop sound like an aeroplane getting ready for takeoff with its continuous indexing, while making generous use of the existing memory.

Needs additional configuration for what the others do out of the box, like Javadoc tooltips.

Requires ten finger shortcuts.

It is also the only Java IDE unable to do mixed language debugging, Java/C/C++.

> JetBrains is just one company whose core set of products are rapidly being encroached upon by free alternatives

This has been true for almost two decades now - Eclipse first shipped in 2001, and it competes directly against IntelliJ, which was JetBrains' main product at the time.

And yet, they're still around.

> Another huge advantage Kotlin has over Scala is tooling, which is basically all thanks to an IDE company creating the language. Tooling will never fall behind because they are in the business of selling tools.

Not sure I'd agree with this. Kotlin's ties to JetBrains means that you're basically hosed if you don't use IntelliJ. Scala's tooling works pretty much everywhere (LSP/Metals, ENSIME, IntelliJ, Eclipse/Scala-IDE).

> Scala's tooling works pretty much everywhere (LSP/Metals, ENSIME, IntelliJ, Eclipse/Scala-IDE).

Scala's tooling also pretty much sucks everywhere (interestingly the least sucking IDE for Scala is guess what ... Intellij!)

In my experience IntelliJ is a bad Scala IDE. While it has lots of cool advanced features, none of them make up for not being able to compile the basic language accurately: what good is an IDE where I can't 100% rely on getting a red underline for invalid code and no red underlines for valid code?

The parts where IntelliJ has always fallen down on Scala seem to be precisely the parts that are missing from Kotlin. I can't help feeling that the JetBrains team just "doesn't get" higher-kinded types at all. Which is a shame, because there is a lot of good stuff in Kotlin otherwise.

And naturally now they have a vested interest that Kotlin experience just feels better than Scala anyway.

It's improved in the last year or so. It's not perfect by any stretch of the imagination but I find that it's one of the better supported languages out there, second to of course Java/Kotlin/TypeScript/C#.

> Scala's tooling also pretty much sucks everywhere (interestingly the least sucking IDE for Scala is guess what ... Intellij!)

In your opinion.

Personally I almost get depressed when I have to switch from Emacs+Metals to Android Studio for Kotlin stuff.

ENSIME was abandoned several years ago because the maintainer felt bullied[1] and LSP/Metals has a ways to go.

[1] https://medium.com/@fommil/hide-your-real-name-in-open-sourc...

As long as nothing bad ever happens to JetBrains.

(You could say the same thing about Sun/Oracle...risks all around.)

> Dead

It's being maintained. A new version (3 iirc) is about to come out. But it's not a hot bed of innovation.

I think Kotlin now already has a lot more mindshare and corporate interest behind it than Groovy ever did.

Groovy had first class support on Spring and Sun was doing talks at JSFDays on how it would become the JEE scripting language.

Those of us that are part of the Java world since the early days, have been through this multiple times.

Grails is 13 years at this point and still the only way to take advantage of the JEE Java ecosystem while also leaving your sanity intact. Since Grails 4 it is slowly moving away from Spring to Micronaut so the JEE ecosystem may die before Grails does.

That is irrelevant for Java as platform and programming language, just libraries that come and go, Java stays.

Just like C on UNIX, JavaScript on the browser, ....

> Those of us that are part of the Java world since the early days, have been through this multiple times.

The hype curve is definitely in the past, but Groovy is living on quite well as a small but viable option in the plateau of productivity. In some ways that is more important because while in the hype phase it is really hard to judge the true value of a technology. The true value emerges when the hype is over.

The problem is, there isn't really a better scripting option for the JVM. While in theory lots of JVM languages (JRuby, Jython ... etc) could fill that gap, they all have ugly impedance mismatches which Groovy doesn't, so companies continue to deploy it as a scripting and DSL implementation still. I tried to substitute Kotlin for a bit and went back to Groovy because Kotlin still lacks standard scripting constructs such map and list literals etc.

> Those of us that are part of the Java world since the early days, have been through this multiple times.

Right, history repeats itself all the time ... until it doesn't. 10 years ago is not now, Kotlin is not Groovy ...

Indeed, Groovy did not had an OS to sell it alongside.

don’t forget gradle and jenkins

Gradle is moving to Kotlin. I would be surprised if Jenkins wouldn't follow to move away from Groovy.

Note that with Kotlin, JetBrains created it initially for working on their IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a good indicator of long-term sustainability.

Nowadays there are trying to just get Kotlin anywhere and it remains to be seen how Valhalla and Panama will be usable from Kotlin.

Panama would not seem to pose any problems as it's all code generation with MethodHandles/VarHandles. That should be directly callable from Kotlin.

As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.

Kotlin inline classes are heap allocated, they are just syntax sugar for regular classes.

One cannot just change their semantics after the fact.

Kotlin's inline classes (and Scala's AnyVal classes) are syntax sugar for static methods. The object itself is erased completely whenever possible (just like primitive values).

Which is not the same as the semantic meaning of doing stack allocations or being stored in registers.

The following:

    case class Foo(x: Int) extends AnyVal {
        def square: Int = x * x
    }
    val bar: Foo = Foo(5)
    println(bar.square) // => 25

Compiles down to (the moral equivalent of)

    object Foo {
        def square(x: Int): Int = x * x
    }
    val bar: Int = 5
    println(Foo.square(bar)) // => 25

If the inner value (x, in this case) can be stack-allocated or stored in registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a supertype of Foo) will be autoboxed, but that also applies to primitive types (`5: Any` becomes a java.lang.Integer in memory).

Neither of those represent the same semantics of:

    inline class { ... ]

Which is guaranteed to be always stack-allocated or stored in registers, again you cannot retrofit semantics, specially when passing those classes to binary libraries.

You're correct that the Scala version isn't ABI-compatible. But Scala doesn't care about ABI between minor releases anyway, so that probably wouldn't stop them from changing it to align with Java.

There is also precedence for this, Scala 2.12 changed the encoding of lambdas from anonymous classes to Java 8's invokedynamic.

That cuts both ways though. If JetBrains goes away or something shifts their corporate interest away from that then Kotlin has zero support at all. Whereas other languages are built on grass roots foundations. It's certainly unlikely in the short term but it's hard to say long term about the future of any company.

Yeah, it's not like it's a Google project. You can probably expect JetBrains to support Kotlin going long into the future.

SUN was supposed to be here forever as well...

I still love groovy, it doesn’t need to evolve that much to be useful for the things it’s good at, like parsing unstructured data and making boilerplate free pojos.

This time this is the official android language and there is jetbrains behind it.