Towards Scala 3

It&#x27;s amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves.<p>Yes, some people who previously used Scala, now use Kotlin. And some people who would&#x27;ve used Scala if Kotlin didn&#x27;t exist, use Kotlin. Same probably goes for Rust.<p>But there is a big enough market for people that like the intricate and expressive type system that Scala gives you, in combination with the JVM ecosystem. People that think Kotlin is nice, but not expressive enough, for example. People who don&#x27;t want to deal with Rust&#x27;s memory management and&#x2F;or don&#x27;t have a use for that. People who think Go&#x27;s simplicity is sometimes more of a burden.<p>Why are people so intent to bash sombody else&#x27;s language choices?! Go, Rust, Kotlin, Scala are all great languages in different ways. They all cater to different needs, sometimes radically different (Go vs Scala), sometimes subtly different (Kotlin vs Scala). I think there is a market for all of them, and more. And the introduction of a new language (Kotlin for example) does not necessarily spell doom for another (Scala).<p>Let&#x27;s all enjoy our own tastes and needs, and respect those of others.

So many cool things already done and even more to come. Some parts that excite me as a Scala nerd:<p>* One can now use implicit function types to basically build your own table language syntax that is type-safe. [1]<p>* Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using &quot;==&quot; or &quot;!=&quot;, as opposed to Java&#x27;s forced requirement of allowing you to compare anything with anything. [2]<p>* Null safety checks! Quoting from [3], &quot;Adding a null value to every type has been called a &quot;Billion Dollar Mistake&quot; by its inventor, Tony Hoare. With the introduction of union types, we can now do better. A type like String will not carry the null value. To express that a value can be null, one will use the union type String | Null instead.&quot;<p>* First-class enums, finally. [4]<p>* Erased parameters: you can declare variables specifically for type-safety that _don&#x27;t exist_ during run-time, improving efficiency. [5]<p>[1] <a href="http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;implicit-function-types.html" rel="nofollow">http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;implicit-function-types....</a><p>[2] <a href="http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;multiversal-equality.html" rel="nofollow">http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;multiversal-equality.htm...</a><p>[3] <a href="http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;overview.html" rel="nofollow">http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;overview.html</a><p>[4] <a href="http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;enums&#x2F;enums.html" rel="nofollow">http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;enums&#x2F;enums.html</a><p>[5] <a href="http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;erased-terms.html" rel="nofollow">http:&#x2F;&#x2F;dotty.epfl.ch&#x2F;docs&#x2F;reference&#x2F;erased-terms.html</a>

...ships in 2020?<p>I&#x27;m impressed with what they&#x27;re doing (and love the language), and it&#x27;s hard work, and their speed is faster than, say, Java&#x27;s dead-pace evolution in the 2000s.<p>But, poking around at TypeScript, I&#x27;ve been blown away with the MS&#x2F;TS speed of development. ~2-3 month release cycles, with non-trivial changes to the language (mapped types, conditional types, etc.), that are themselves unique&#x2F;novel type system features, not like Java finally getting around to copying the obvious&#x2F;best-practice approach to case&#x2F;data classes.<p>Granted, I&#x27;m sure the MS&#x2F;TypeScript budget is huge comparatively...<p>Seems like that&#x27;s the &quot;best&quot; (realistic) way for dev tooling to evolve lately: come from, or attach yourself to, a ~top-5 tech company that makes their money somewhere else and can bankroll developer tools&#x2F;languages (e.g. MS with TS, FB with React&#x2F;Flow, Google with a myriad of things e.g. Dart &amp; AdWords, Go).<p>Bringing it back to Scala, seems like they were close to this (flirted with adoption&#x2F;sponsorship from a few startups like FourSquare, etc.) but, thinking about it now, &quot;software development in the large&quot; is a huge concern for those companies (e.g. anyone with enough extra money to actually pay for language&#x2F;tooling improvements), and that&#x27;s never really been Scala&#x27;s strong suit (compile times, painless compiler upgrades).

There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies.<p>I&#x27;d like to share a different perspective based on my own work with OOP-centric and FP-centric languages.<p>If you take OOP to its logical conclusion, OOP is a slippery slope that eventually leads to Gang-Of-Four centric designs.<p>If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs.<p>Both are equally valid ways to design complex applications, so it all comes down to individual taste.<p>Personally I have a taste for mathematical abstractions, so Scala is better suited for my way of thinking.<p>It&#x27;s obvious that Scala was specifically designed to be a solid foundation on which one can implement the concepts of a little known branch of mathematics called the category theory, and almost every design choice in the language flows from there.<p>If we use this as the basis for comparison to other languages, it&#x27;s very easy to understand that Scala has carved out a very powerful niche for itself and is here to stay.

Disclaimer : I&#x27;m nobody important, but I do have an opinion<p>If scala team were to disavow sbt, that&#x27;d be the single best thing they could possibly do for the ecosystem.<p>I used to write a lot of scala, and working with sbt was enough to eventually get under my skin.<p>I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract new learners, especially with just how overwhelming all the different features can seem for someone not coming from both sides. I had ocaml and ruby under my belt when I found scala, so it was an easier curve, but lots of guys struggle with it. I don&#x27;t mind showing them, and of course I learn a lot from guys with different experiences and different backgrounds, but that&#x27;s sometimes a complain I hear, also.<p>It&#x27;s a language that doesn&#x27;t compare very well. What is scala like? We don&#x27;t know, there&#x27;s only one language like it, it&#x27;s a departure from many different paradigms.<p>I&#x27;m back to writing ocaml, all said and done. I enjoyed my time with scala, and interacting with my guys on the other side of the office still doing scala is always enjoyable. Smart guys! I&#x27;m not academic enough to grasp some of the new DOT stuff, but they are excited about it.<p>Anyways, I gave up hope a while back on scala getting rid of sbt. There are other build tools that exist, cbt, mill, maybe more, but without the blessing from lightbend or whatever they call themselves this week, it&#x27;s not feasible, or responsible to deliver a solution to a client with an unofficial build setup. Of course, after five years of doing sbt I decided it&#x27;s not ok to deliver sbt either.<p>Someday! Maybe?!

&gt; Scala 3 code can use Scala 2 artifacts because the Scala 3 compiler understands the classfile format for sources compiled with Scala 2.12 and upwards.<p>I feel like this isn&#x27;t getting much attention but it is a huge deal. A big part of the reason that Python 3 went the way it did was users didn&#x27;t want to upgrade until their libraries did and libraries didn&#x27;t want to upgrade until their users did. With Scala 3, users can upgrade pretty rapidly, freeing libraries to upgrade without fear of leaving their users behind.

Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting &quot;better Java&quot; all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml&#x2F;Reason (for the more unixy world). And the academic&#x2F;research&#x2F;learning crowd seems to like Haskell more.<p>Who&#x27;s still in Scala boat? Are Google or Fb or other big cos known to give back to open-source growing any Scala codebases now?

How have people faired with Scala integration with Java libraries? When Scala first came out, I liked the idea. If I wanted to use X library, great, I can. As I pondered it more, this seemed terrible. Say I hug the functional side of Scala. I know what I&#x27;m doing. Then I hire a Jr Dev. She comes from the world of Java&#x2F;Python where functional is no as big of thing (keeping in mind that while Python does support, to a degree, functional, many use it as a procedural&#x2F;OO language in school). Suddenly I have to worry about the Jr Dev doing silly things like introducing mutable Java objects into functional code. Side effects could start to show at odd times, which makes debugging terrible in a production environment.<p>All that said, how have others dealt with this issue? Did you just not work directly with Java libraries? Did you use the OO side as a Better Java?

My big question (not answered in the FAQ) is will it be faster or slower than Scala 2.12? Having worked on a big Scala codebase, the slow compiler speed is one of the biggest downsides to the language.

I saw a presentation recently on Mill[1] which looks extremely promising and looks poised to remove the giant Scala development headache of working with SBT.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;lihaoyi&#x2F;mill" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lihaoyi&#x2F;mill</a>

This major breaking change to the language reminds me a lot of the Py2-Py3 fiasco. I wonder how Scala&#x27;s community will handle the transition given the previous issues with cross compilation in the 2.x series. Given the multitude of language alternatives in a similar space to Scala, I&#x27;m worried. Fingers crossed they can work through this.

Great news! Kind of confused about scala2 and 3 sharing the same standard library. I thought that was being redesigned.

Last time I tried Scala I had to give up because I couldn&#x27;t understand what a &quot;trampoline&quot; was, or how to use it to get multi-function tail recursion to work. Probably not Scala&#x27;s fault.

Is there any plans to include async&#x2F;await on the language level?

Its fascinating process where if you&#x27;re a hot new language you attract a lot of people that like shiny new things. When the next hot new language comes along and those people move on - have you attracted enough of the secondary wave to keep alive? Its going to be interesting to watch Scala adoption in the next few years.

&quot;Scala has pioneered the fusion of object-oriented and functional programming in a typed setting.&quot;<p>What about Ocaml (1996, well before scala) and F# (2005, not too long after scala)?

Well it won&#x27;t solve the biggest problems with interop <a href="https:&#x2F;&#x2F;github.com&#x2F;scala&#x2F;collection-strawman&#x2F;issues&#x2F;283" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;scala&#x2F;collection-strawman&#x2F;issues&#x2F;283</a> (sadly).<p>I mean I can understand all the reasons not to, however It&#x27;s just a pita that there is no sane way to do it, besides reimplementing either two api&#x27;s or come up with your own collections.

As a heavy Scala user I&#x27;m excited by this. But really I don&#x27;t think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow).<p>Personally, for a lot of my current use cases (APIs) I&#x27;m veering towards Go more and more as I find it a lot more productive.

&gt; Simplify where possible<p>&gt; eliminate inconsistencies and surprising behavior<p>Oh dear god please.

I was really hoping they implement python-ish syntax <a href="https:&#x2F;&#x2F;github.com&#x2F;lampepfl&#x2F;dotty&#x2F;issues&#x2F;2491" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lampepfl&#x2F;dotty&#x2F;issues&#x2F;2491</a><p>But no, &quot;Implicit Function Types&quot; instead. Ok.

&gt; become more opinionated by promoting programming idioms we found to work well<p>Which idioms exactly?