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.

> 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.

Scala 3 supports braceless syntax, aka significant indentation, aka "YAML is to JSON as Scala 3 is to Scala 2"

https://dotty.epfl.ch/docs/reference/other-new-features/inde...

There was quite some debate on this, going on strong.

I consider this a totally useless "innovation"! As if Scala didn't have already enough possibilities to express things, no we are able to leave out braces, what makes scanning code even harder and will lead to an ugly mixture.

I would accept it, if they would decide to drop the traditional syntax. But adding yet another style, just for the sake of it, is waste of resources (of the Scala creators and Scala users).

There is a good article about the "strangeness budget" of languages, and I think that Scala doesn't spend it wisely. https://steveklabnik.com/writing/the-language-strangeness-bu...

Yuck... personally I'd want a Lint that would disallow many such syntax differences from Java: - force use of () - force use of ; - etc...

Yeah there are certainly some Python 2/3 fears for Scala 3, but the plan and upgrade path seem much more thought out

Is there a document with the differences between 2.13 and 3?

https://dotty.epfl.ch/docs/reference/overview.html and associated pages.

I was also asking me for such details. Thanks.

The crucial point here is if Scala 3 maintains backwards compatibility with Scala 2.x. If not, it's effectively a new language and then the game becomes which of the existing scala code bases will switch over and when. There's a large amount of existing Scala code out there and embarking on a migration of that stuff is going to take very long. We're talking many years here potentially. The few Scala projects I've dealt with, even updating to minor releases of Scala was a big deal.

The python 2 to 3 transition took well over a decade. You have similar discussions in what remains of the Perl community around v5 and v6. IMHO what Oracle has been doing with Java in recent years is impressive in the sense that they provide a credible upgrade path and put a lot of effort into that while still adding non trivial new language features. But it has a price of added complexity or compromises with new features and unfortunate legacy features that are not going to way. Javascript and typescript have the same issue. Javascript has a lot of weird legacy features and typescript preserves backward compatibility with that weirdness and attempts to engineers around that.

I'm currently using Kotlin across Android and Server (mostly) with an intention to also use it on IOS and Web very soon. Its multi-platform capability is increasingly a good selling point and I love how that ecosystem is booming in the last year/months. I'm definitely an early adopter of multi-platform but this seems to be one of those things where it seems like a bet worth making at this point.

Kotlin is of course a much younger language so it does not have a lot of legacy yet burdening it. Yet, Jetbrains seems to be good at managing new features while minimizing disruption, dealing with necessary deprecations, and generally not breaking compatibility. Their experience as tool makers gives them a unique edge over a lot of other languages.

Arguably Kotlin emerged as a rejection of Scala to replace Java by Jetbrains: they considered it and dismissed it as an option and then embarked on a journey to create their own language. I think the success of the language (relative to Scala) seems to indicate that that wasn't a bad choice. Scala intended to do many of the same things but it just never caught on with people actually doing those things to the extent that Kotlin seems to be catching on. The transition from Java to Kotlin is a lot less of a hard sell than the transition to Scala was. Though I know plenty of people that stubbornly stick with Java still. Of course early adoption in the Android community was a big deal. But then you could argue that that same opportunity was there for Scala to take and I don't think much serious effort ever was put in that notion. The need for something else than Java was quite big there and a big driver for this. All Kotlin did was provide a credible upgrade path to Java developers and the Android community jumped on it because it was easy to switch and obviously better. You see the same happening in the Spring community which is increasingly Kotlin centric.

Meanwhile Scala seems to be bleeding mind-share to more pure (for lack of a better word) languages Crystal, Elixir, etc. or more system oriented languages like Rust, or indeed Kotlin. It's a bit of a repeat of what happened to the Ruby community a few years ago. Certain types of people were very passionate about that language for a while and then moved on.

> The crucial point here is if Scala 3 maintains backwards compatibility with Scala 2.x.

The Scala team is keenly aware. Scala 3 can use Scala 2.13 libraries - in fact the 3.0 stdlib is the exact same .jar as the 2.13 stdlib - and a future version of 2.13 will be able to use scala 3 artifacts as long as it doesn't use 3+ only language features.

More details at https://scalacenter.github.io/scala-3-migration-guide/docs/c...

Except Macros. So a lot of stuff.

Yes, but they're mostly constrained in libraries and there's a way to publish them so both 2.13 and 3 can consume them. You can expect "core" ecosystem libraries to be cross-published and most others don't depend on macros.

Note that most things you'd need macros for in 2.13 have language support in 3, so for user code - if that even uses macros at all - the upgrade path is fairly straightforward.

I have a pretty large codebase written in scala 2.12 or so (whatever the version was around late 2018). I'd like to migrate it to scala 3. Any ideas how hard it'll be?

Start with migrating to scala 2.13, scala 3 can run all non-macro 2.13 code that doesn't emit deprecation warnings and can consume most 2.13 libraries. The widely-used ones it can't will get updated.

For more information see https://scalacenter.github.io/scala-3-migration-guide/docs/c...

Pretty easy unless you were writing custom collections or custom macros, IME.