
The Road to Scala 3 - nuriaion
https://www.scala-lang.org/2019/12/18/road-to-scala-3.html
======
jacobn
I love scala, and am very much looking forward to scala 3.

For all the complaints about the language that always pop up in these threads:
yes, the language lets you shoot yourself in the foot (with great power comes
people who don’t apply it responsibly), but it’s precisely that power that
makes it so useful and exceptional when judiciously applied.

I like to say that scala is as if java and ruby had a love child and it all
worked out. Unfortunately, that does mean that java people will feel it’s too
fast & loose, and the ruby people will feel stymied by its static typing. But
I just love that where other statically typed languages generally say “no”,
scala says “well, I trust you know what you’re doing...”.

The only substantive tool complaint I have these days isn’t with compiler
speed - it chugs through the codebase plenty fast - but with tool startup
time. Hopefully the more recent java versions and maybe some native packaging
will eventually help with that.

~~~
asimpletune
I appreciate you taking the courage to share your honest thoughts despite how
they may conflict with the views of others here. My heart goes out to the
people I overhear at work, the ones who are struggling the most, lamenting and
complaining that tool X (In this case scala) is “so” embarrassingly awful and,
with the implication that it’s to blame for their poor performance. That
sentiment resembles some of the comments that I’ve written here and my heart
really bleeds for them, because I know these people at work and I know that
they’re struggling and I also know that they’re good, smart people, who have
just fell into a trap of justification.

For what it’s worth, in my own journey learning Scala, I simply didn’t have
the luxury to blame, and I just forced myself to try and figure out how other
people, like the finagle team for example, could be so productive with such an
obviously newfangled invention, until I realized… I was wrong.

Scala is actually a wonderful language! People move companies to continue
working in Scala! In fact the ideas and lessons that I’ve learned from
rethinking how I used to do things are so unfathomably valuable to me that I
don’t think I will ever look at code the same way again.

And before you downvote me please don’t mistake my words for criticism. I
truly empathize with how some of the people here may feel and I’m very happy
to go into specifics if anyone requests that. I don’t write on HN a lot
because a lot of times I think there is just this therapy - or a version of
therapy - that amounts to people reinforcing their need to blame things in
order to continue excusing the poor performance, and I don’t want to get
caught up in it or be made to feel bad for encouraging others to reconsider
their virtues.

And by the way we all, at times, have poor performance. (Anyway, I dictated
this into my phone, so also excuse any weird words or punctuation. I love you
all. Some typos were subsequently edited)

~~~
bcrosby95
Not every language has to be for every person. It's perfectly fine that people
enjoy Scala. I think a lot of the negativity about Scala is because lots of
companies went in hard on Scala less because of the merits of Scala, and more
because Java had such a long period of stagnation.

~~~
asimpletune
This is very true

------
lihaoyi
The way I look at modern Scala is a mix of Python and Java.

Do it badly, and you end up with the unmaintainability of Python and the
clunkiness of Java. Awful.

Do it well, and you end up with the convenience and interactivity of Python
and the typesafety, performance, and toolability of Java.

This lets you implement your code quickly the first time, and have it run
blazing fast on a hot JVM, with the compiler having your back as you grow your
codebase in size and complexity. Sure beats trying to prototype in Java, or
porting half your Python prototype to C when you realize it’s too slow.

Scala has a bad reputation, well-earned due to an early culture of crazy
experiments, crazy operators, and crazy tools. But those days are behind us.

You can no longer get stuff into the standard library “just because”, and a
lot of the early experiments in that category (xml, parallel collections,
parser combinators) has been consciously moved out.

Operator-heavy tools like SBT have largely replaced the crazy operators, while
operator-heavy libraries like Dispatch have been largely replaced by less-
operator-heavy equivalents.

SBT used to be awful, but it’s improved a lot. And you don’t need to use it: I
haven’t touched an SBT build in years by now, in both OSS and proprietary
contexts.

There remains a lot of different ways to write Scala, more than most
languages, but you don’t need to write Haskell-in-Scala unless you really want
to.

I’m personally very happy with my Python-like language with Python-like
libraries, with static typing for maintainability, orders of magnitude better
runtime performance, excellent parallelism and concurrency, one of the best
compile-to-JS experiences in the world, and the best tooling (IDEs, profilers,
monitoring, etc.) on the market.

As someone who maintains optimized programming language interpreters,
distributed backend clusters, three-tier web apps, command-line tools, and
many other things on a daily basis, I appreciate being able to do all this in
one language rather than juggling 5 different languages (and 5 different sets
of libraries, and 5 different sets of tools, ...) to satisfy each use case.

Scala may be diverse and fragmented, but it’s not as diverse or fragmented as
the polyglot Python/Ruby/C/Go/Javascript codebase it would likely take to
replace Scala for my daily work

~~~
esarbe
That's about my experience. The language is maturing very well and the library
ecosystem is just amazing. (Looking at you, lihaoyi!).

I really appreciate that I can walk the full gradient from immutable-
functional to impure-imperative with one language, depending on the context
and the requirements. It takes some discipline for a team (code reviews,
regular feedback, discussion on approaches) but I'd say that's true for any
language to some degree.

Then there is the ecosystem that's getting better and better with every year,
with more and more libraries building on and onto each other.

SBT has been a sore point in the past, that has been ameliorated quite a bit
in the past three years. SBT 1.3.x together with GraalVM native is a game
changer! And then there are lots of other build tools that less ambitious and
more approachable than SBT, if SBT simply isn't your cuppa.

Scala.js is also quite amazing. Scala is definitively underrated in that area.
Being able to stay in one tool for a full stack application and being able to
shift code seamlessly up and down the stack, depending on the current
requirements has been an eye opener for me.

Biggest Scala pros \- Terse expressive syntax with a strong type system \-
Welcoming community and creators \- Amazing libraries and rich ecosystem \-
World-class tooling!

I the future I hope that Odersky and the core team will continue to identify
"implicits" use cases and provide dedicated syntax for them, just like they
did with extension methods in Scala 3.

~~~
AheadOfTime295
Scala 3 has been around for seven years on Github
[https://github.com/lampepfl/dotty/commit/2308509d2651ee78e11...](https://github.com/lampepfl/dotty/commit/2308509d2651ee78e1122b5d61b798c984c96c4d)

Scala.js and Scala Native will support Scala 3 eventually.

SBT isn't nearly as bad as it used to be. It's an open question how much more
it will "improve".

~~~
esarbe
> Scala.js and Scala Native will support Scala 3 eventually.

I'm looking forward to it! Now that the Dotty experiments come to an end and
development of the Scala language shifts away from Scala 2.x to Scala 3 I
think this becomes feasible!

------
solicode
I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's
unlikely for Scala to have a second renaissance and have an steep upward
trajectory like those languages, but is that really a death of a language? I'm
actually fine with Scala narrowing its scope and focus at being really good at
just a couple of things. Such as embracing its FP-side more so than its OO-
side. Not to say there is no value in its OO-side (I still see some value
there mostly pertaining to modules). But I just mean that not every language
needs to aim to be a top 5 language. FP and advanced type systems still seems
to alienate a significant percentage of programmers for various reasons.
That's fine. It's not like that sentiment is going to change overnight.

Scala missed its opportunity with Android. I think you just have to concede
that to Kotlin at this point and just focus on moving in a direction that is
not occupied. Which is why I mention FP with a strong focus on types. There's
not much competition there besides Haskell. And since Haskell for the JVM will
likely never be a thing (a few have tried, but none have gained traction),
Scala is still there. And with the direction Scala 3 is going and all the
improvements it brings, it's actually looking quite positive. At least in my
eyes.

And besides, I don't think Scala has to be a "worse Haskell" in everything
that it does. I think ZIO is a good example of a great Scala library that
actually resulted in something really special by embracing what Scala can do:
[https://zio.dev](https://zio.dev)

~~~
melling
What is the story with Scala on Android? Years ago I thought it was a matter
of using too much memory. There’s not much talk about it but it does seem to
be possible:

[https://scala-android.org/](https://scala-android.org/)

Will Scala 3 help?

~~~
oxnrtr
As the person who was involved in Scala on Android (and particular in creating
the website), I'll chime in with this:

What sunk Scala on Android was largely the completely lack of interest from
the core team.

Everything that Scala on Android achieved was pretty much _despite_ the
actions of Scala's upper echelon.

\- It's hard to get a good message out, when core members spread FUD by
bringing up problems that were solved year ago (like the big std lib issue).

\- The core team's perception of Scala was always inward – new platforms
existed such that Scala developers could run their code in more places, not
because it could attract new developers from these existing ecosystems to
Scala.

(Scala.js partially overcame this by herculean efforts of individual members
of the Scala.js community that got the word out to the JavaScript world about
Scala.js.)

\- Core Scala pulled the plug from Android support in the backend. So Scala on
Android was pretty much left to die on an outdated Scala version.

\- Something like TASTY (an interchange format that can be recompiled on the
fly to target new backends), which could have dealt with the problem above –
was promised for years, but still hasn't shipped.

\- The core team was against even acknowledging the existence of Scala on
Android on the website – good luck in convincing that Scala on Android works,
if the official website/documentation doesn't mention it with a single word.

\- Core Scala treated the main contributor with so much public disrespect,
that I'm still surprised he didn't outright quit back then. It takes balls to
publicly blame the main contributor of Scala-on-Android for not working on the
project full-time, but also conveniently managing not to tell him this crucial
"requirement" for half a decade. And with "full-time" I mean "unpaid full-
time".

It's a sad story, because Scala-on-Android shipped with some amazing features
like hot-code-replacement years before Google managed to ship it. The typed
resources stuff was also pretty impressive.

~~~
oxnrtr
So, no, Scala 3 won't help. Most people who cared left years ago.

------
maxaf
When I gave up on Scala in 2016, I did so because its future looked fragmented
and uncertain. Fast forward more than three years, and the first release of
Scala 3 won’t be out until another year from now. Compare this with the pace
of development of Go or Rust: those languages are driven by a vision, and have
a dedicated team behind them. Scala is declining because no one could figure
out for the longest time what was next and how to work on it.

It’s too bad, as Scala did the most of any language to bring me into the fold
of statically typed programming. I miss it sometimes, but then I remember all
the times Scala wasted my time, and get back to writing Go like a happy little
camper.

~~~
haggy
> Scala is declining And the proof of this is... Where?

~~~
maxaf
I won’t even mention the anecdata from my own workplace. I’ll only say that
within my extended network people are frantically rewriting Scala bits in
other languages. Those who are stuck with it (because of, say, extensive prior
investment into Spark) are scrambling to come up with alternate solutions.

Put your ear to the ground, and you too will hear it.

~~~
xvilka
There is an ongoing work on creating Spark alternative in Rust[1][2].
Hopefully, that could help.

[1]
[https://github.com/rajasekarv/native_spark](https://github.com/rajasekarv/native_spark)

[2] [https://medium.com/@rajasekar3eg/fastspark-a-new-fast-
native...](https://medium.com/@rajasekar3eg/fastspark-a-new-fast-native-
implementation-of-spark-from-scratch-368373a29a5c)

~~~
pkolaczk
Will take years to get there, if they even get there at all. This is a single-
man side project now. Also benchmarking something that has 1/100 of the
original functionality and is not production ready is very unfair. It is much
easier to get a specialized use case faster than a general purpose system.

------
melling
I see a lot of people complaining about Scala. I looked into it 9 years ago
but it didn’t seem to be gaining traction so I stopped playing with it:

[https://github.com/melling/scala](https://github.com/melling/scala)

Recently, however, I’ve noticed that Scala does to be be quite alive (3.0,
ScalaDays, Cats, Shapeless, Scala.js) so I’m taking another crack at it.

I’ve done a lot in Swift and it’s my current favorite language, but it’s not
widely supported.

When I look at Scala (especially 3.x), I feel like it’s like a Swift++. Go is
a great language but I want to move up a level of abstraction.

By the way, Scala 3 is now feature complete:

[https://www.reddit.com/r/programming/comments/edcenz/dotty_s...](https://www.reddit.com/r/programming/comments/edcenz/dotty_scala_3_feature_complete/)

~~~
saagarjha
Swift seems to have taken a number of its early ideas from Scala, particularly
around some of its functional concepts.

------
dominotw
I switched to clojure for a new job from doing scala for 5 years. I just feel
a weight has been lifted off of my head. Weight of syntax, slow compilation,
weight of implicits ( some of them are so bad even editors like idea couldn't
figure out what is going on). And most importantly the weight of the constant
feeling of not being able to fully understand the meaning of endless math
terms thrown at me casually like monads, freemonads, applicatives ,
categories, Kleisli ect.

I spent so much time learning what all these math concepts apply in
programming but now I don't remember what any of these mean anymore and I am
still shipping production applications ( in clojure). Sigh, what a waste of my
life doing scala :( .

~~~
leetrout
This touches on a difference between the Go and Scala communities and courses
from my very brief experience learning scala for work the past couple months.

The older I get the more I want things that are explicit and easy to
understand. Tons of sites and videos and blogs exist that break down the
features of Go without a ton of math lingo. I never see Scala materials free
of that. Even when I agree that I need to understand the terms of art I
haven’t been in a math class in 16 years and it’s slow going. With Go I was
productive in two days and proficient in less than two weeks. Yes I still
shoot myself in the foot with channels and race conditions when I’m rushing
but at least it’s a super fast compile cycle to iterate and my IDE doesn’t
require over 2gb ram like scala / idea does.

~~~
yahyaheee
Yup being easy to understand without lacking functionality is definitely
superior to supporting every insane programming concept. It builds stronger
communities and better software

~~~
jkachmar
Big ol’ “Citation Needed” on this one.

The flip-side here is that a language that doesn’t support basic programming
language theory concepts dooms its users to repeat the mistakes of those who
discovered them.

I also would personally disagree that any statically types language without
generic types and without non-nullability (e.g. `Option`/`Maybe` and
`Result`/`Either`) is severely lacking in the ability to express programs that
are easy to understand.

~~~
yahyaheee
proof is in the pudding on that one, sorry don't think there are academics
studying this but it's an obvious outcome from the war that was Go/Scala/Node.
Go is eating Scalas lunch because its easy to understand and communities are
stronger than individuals. Sure Scala has more 'features' but Rob Pike would
say every feature has a cost and you need to weigh that, didn't see that ever
happen in Scala. Go is taking the time to get each piece right and I'm glad
for it.

~~~
jkachmar
Another commenter points out that Go has Google backing it, which is a
significant confounding factor in terms of figuring out how good it is on its
own merits.

I’ll add to this and say that Go is a language that is very well-suited for
Google’s issues. Namely, take a bunch of engineers with a particular area of
familiarity (e.g. familiarity with C and/or Java) and throw them at code,
scaling up by number-of-engineers where necessary.

My issue with pointing to this and calling it “practical” and “easy to
understand” is twofold:

(1) Go implicitly makes its ease of understanding dependent on an having
existing background knowledge of concepts that the HN crowd is likely to have,
themselves, which biases people but isn’t particularly easy to learn on its
own merits (versus, say, Python)

(2) Most companies cannot afford to solve engineering problems by throwing
more bodies at it, but with Go your option is either that or leveraging
external code generation

As far as “taking the time to get each piece right”, this stuff isn’t cutting
edge technology development! Go isn’t doing dependent typing or borrow
checking or scoped effects!

Everything that people lambast the language over not having is old hat, it’s
like defending a car manufacturer who chose to use carburetors over fuel
injection by saying that they’re trying to figure out how to do it right.

~~~
yahyaheee
Sorry those just aren't legitimate analogies. As I mention before every
feature has a cost, Go is highly concerned with how those costs impact the
community. In doing so they have created a language thats highly maintainable
and efficient. Even at small companies there is turnover and you being 'really
smart' with some abstraction has an impact, I've seen this plenty first hand.

~~~
jkachmar
Counterpoint, regarding community: the Rust programming language has a much
more vocal, cohesive, and engaged community than Go does in my experience,
even though it has a fraction of the corporate backing.

Counterpoint, regarding “reducing the cost of features”: Go is spreading a
simplified understanding of what garbage collection performance means to a
generation of programmers by providing almost no configuration over their GC
settings. I’ve had people say that Go’s GC is obviously the best, without any
point of reference with which to compare it.

What Go has done here is pick a reasonable set of trade-offs to make in their
garbage collector, hard-code most of these settings into the runtime system,
and package that into the philosophy of “configuration is bad”.

~~~
yahyaheee
Rust has a pretty great community, and I don't think you need corporate
backing for a community. I'm just stressing it's one of the most (if not the
most) important aspects of a language.

I will say Rust it isn't nearly as easy to enter as Go, that should be
somewhat expected by their desired feature set. Likewise, they aren't as
concerned with the cost of features as Go is.

I would somewhat agree with the GC stuff, I think having a couple more levers
there with sensible defaults is probably ideal.

------
noelwelsh
This is fantastic. Scala 3 is a huge improvement, doing away with main of the
pain points of Scala 2 and making using Scala effectively much more
straightforward. I'm looking forward to getting to work with Dotty / Scala 3.

~~~
playing_colours
I’m looking forward to reading new books on Dotty from underscore then :)

------
sgt
The more I read about Scala it makes me wonder why (1) I am not using it (or
my team) (2) Java teams across the world are not at least seriously
considering changing to Scala. It seems likes it's miles ahead of both Java
and even Kotlin.

~~~
apta
> Java teams across the world are not at least seriously considering changing
> to Scala.

I've used Scala before. It has challenges that would make it a non-starter for
many teams. It has some cool features, but those (IMO) don't outweigh the
negatives that come with the language: it's overly complex (different people
have very different styles for writing the language), the compiler is slow, it
generates more garbage than Java, lots of implicit behavior, the standard
library is not up to par, among others. Java is improving significantly in the
coming few releases: pattern matching, records, switch expressions, etc. will
bring to programmers the bulk of what Scala has to offer without the added
weight. Kotlin is a much better contender for most teams anyway, and even that
will be a challenge IMO.

~~~
dxxvi
If I read it correctly, you said "Scala standard library is not up to par",
"Java is improving significantly in the coming few releases: pattern matching,
records, switch expressions". I see the other way around: Java 14 records,
pattern matching and switch expressions are like a joke compared to Scala case
class and pattern matching. For example, does Java 14 Stream have any method
equivalent to `collect` in Scala, which is a combination of filter and map?

~~~
apta
> Java 14 records, pattern matching and switch expressions are like a joke
> compared to Scala case class and pattern matching.

What does Scala's pattern matching do that Java's (upcoming) doesn't?

> For example, does Java 14 Stream have any method equivalent to `collect` in
> Scala, which is a combination of filter and map?

Not that I'm aware, but then again, I don't see the large advantage compared
to making two separate map + filter calls. Streams in Java are lazy, whereas
calling `map` or `filter` on a concrete collection in Scala is eager, creating
temporary intermediate collections only to discard them in the case of
chaining calls.

~~~
dxxvi
An example of Scala's pattern matching:

    
    
        case class Person(name: String, age: Int)
    
        // a collection of 3 people
        val c1 = Vector(Person("A", 5), Person("B", 6), Person("C", 4))
    
        // now I want a collection of people who have age > 4 and then their ages are doubled
        val c2 = c1 collect { case Person(name, age) if age > 4 => Person(name, age*2) }
    

How do you write it in Java 14? Want something lazy like Java streams? It's
LazyList in Scala 2.13 and Stream in Scala < 2.13.

~~~
sorokod
In Kotlin

    
    
        data class Person (val name: String, val age: Int)
        val c1 = listOf(Person("A", 5), Person("B", 6), Person("C", 4))
        val c2 = c1.filter{ it.age > 4 }.map{ it.copy(age = it.age*2) }

~~~
dxxvi
Kotlin and Java don't have a powerful pattern matching like Scala. Maybe
that's why they don't have `collect` for filter + map. However I'm learning
kotlin now because my employer doesn't allow me to use Scala

------
ccthr
To all those saying Scala is dying:

Personally I am making top money on Scala gigs, and I don't see that changing
anytime soon. The people I meet on these gigs share my opinion. Most people
wouldn't take a Java job even if it paid more, same for Go or Node ( both of
which I have used in production in the last month, and wouldn't take over
Scala, with the exception of serverless)

Teams in Media, Government and Finance are leveraging Scala to do things that
take Google and Netflix twice as many devs because they use less expressive
languages.

Yes, Go is great because you can scale a team from 1 to 10 to 100 with little
effort. With Scala you get the same stuff done with 20 people.

The people that hate Scala are either Java devs that didn't get it because
they wanted to write inheritance based OOP code and would still be bad devs in
any other lang, or are hiring managers that struggled to get the right people.

This is actually an advantage when you have the right hiring process as you
end up with better developers - they don't need to know Scala, but need to be
open minded to new ideas and motivated to learn.

With all that said, the church of FP and the hascalator community is a problem
for Scala. Overly dogmatic & academic functional programming styles don't have
a place in production systems.

Leverage the type system, immutability and the Future/Option monads and you
eliminate huge swathes of bugs. If you are looking to write "Java on steroids"
or would rather be writing Haskell then you are probably contributing to
Scala's perceived problems.

If you are a startup or small business then Scala isn't a good fit - you're
probably better off starting with JS or Python and moving to Scala when you
have more users and need to deliver something solid. FAANG don't need to use
Scala because they can throw money & devs at problems and therefore favour
languages that fit that modus operandi.

For all the companies in between, Scala is great fit because when you get the
right people you can outmanoeuvre any competition.

One of the earlier comments described Scala as a love child between Java and
Ruby that turned out great. Despite not having used Ruby in anger I agree with
the sentiment as I believe the best way to write Scala is as a statically
typed Ruby for the jvm. It's supposed to be simple and elegant, and the best
Scala devs realise this. To re-iterate my earlier statement, if you are trying
to write something "oop" or "pure fp" then you are getting it wrong.

~~~
Bahamut
FWIW, I'm in a FAANG and finding Scala devs is even a problem within my own
org and team. We've resorted to teaching largely Java devs Scala on the job
with mixed results. A former senior manager who made the decision supposedly
viewed going all in on Scala as a mistake in large part due to the huge time
loss in ramping people up & problems hiring.

I like what I've used of the language at work, although I tend to write a lot
of JavaScript on a day to day basis, but to say the right hiring process makes
Scala an advantage is not quite right in my own experience.

~~~
ccthr
Hiring Java devs is the problem. It's a lowest common denominator language.

Try looking for Ruby or JS devs. It's a lot easier to teach someone from a
dynamic background how to leverage a type system than it is to teach an
imperative developer to write side effect free code. State is a crutch.

~~~
Bahamut
They just happen to be people who has done Java - we hire the best devs we
can, regardless of language experience (my own team has interviewed/hired
people who have done primarily Python, Ruby, JavaScript, Clojure, and/or
Java). A couple turned out pretty well, but several turned out to be much more
junior than we expected. I should add that I have no love for Java myself, I
rather not be writing Java at all if I can help it.

If there is one thing this profession has taught me about hiring, it is that
it is very difficult to predict who the top performers will be. Blanket
assumptions will often prove to be not true when searching for the cream of
the crop.

------
pinopinopino
I love Scala, it has a nicely advance static type system, supports functional
programming and has even macros, although they are a bit messy. Something I
miss in go and python. Go's type system is way to simple and python is
dynamic, which I think is unnecessary these days. Static type systems can be
as expressive as dynamic ones. It has interesting libraries, like cats,
shapeless, breeze. And it is popular in the big data field.

~~~
esarbe
Yeah, the thing with macros is that they were never officially supported. They
were always kind of a hack.

Scala 3 finally has an answer for that[1].

Besides that; yeah, Scala is amazing. I really see it shine for scientific
computing when it moves beyond Python.

[1]
[https://dotty.epfl.ch/docs/reference/metaprogramming/macros....](https://dotty.epfl.ch/docs/reference/metaprogramming/macros.html)

~~~
pinopinopino
It looks much cleaner and pleasant to use. Perhaps time to play around a
little bit with dotty.

------
jatcwang
I was initially skeptical of Scala when I landed my first Scala gig a few
years ago, but now I'm really glad I picked it. Simple things like pattern
matching and immutability are amazing, and Implicits + Macros enables some
awesome libraries like Shapeless[1], Chimney[2] which solves real business
problems in a succinct and type-safe way.

Very excited about what's coming in Scala 3

* Lots of improvements to make the language simpler and easier to work with * Integrating some tried-and-true patterns from the current Scala ecosystem directly into the language * First-class tooling to solve some long-standing issues in the ecosystem (binary compatibility)

The team behind Scala 3 has done a tremendous job. Along with the whole
movement of better tooling that's happening in the Scala ecosystem right now,
I think the language will have a fun and productive future!

[1]:
[https://github.com/milessabin/shapeless](https://github.com/milessabin/shapeless)
[2]:
[https://scalalandio.github.io/chimney/](https://scalalandio.github.io/chimney/)

~~~
AheadOfTime295
Macros and their migration path to Scala 3 have been discussed at the Scala
Center, EPFL
[https://scala.epfl.ch/minutes/2018/12/05/december-5-2018.htm...](https://scala.epfl.ch/minutes/2018/12/05/december-5-2018.html)

------
devit
The problem of Scala is that it is outclassed by Rust and Kotlin at its two
niches of, respectively, "best designed programming language" and "better Java
on the JVM".

Scala can't beat Rust because you can't have safe concurrency (and also
single-threaded mutation control) without linear types, and you can't have
linear types on the JVM; furthermore, a GC and VM-based language is inferior
to a native non-GC one providing the same guarantees.

Scala can't beat Kotlin because Kotlin is designed to be just a better Java
and Scala also tries to do other things that reduce Java compatibility;
pivoting would result in being behind Kotlin with no hope of catching up.

Furthermore, its core features are cute but fundamentally broken: class
inheritance is an anti-pattern and functional features need either purity like
Haskell or mutability control like Rust to work safely and efficiently; on top
of that, the language is also complicated and hard to learn.

~~~
bmc7505
> you can't have linear types on the JVM

Why can't you have linear types on the JVM?

~~~
MrBuddyCasino
I don't get it either - its a compiler construct, not a runtime check
(remember Rust's "zero overhead" motto).

------
bcherny
I really love Scala, but I worry about its future given Google putting its
weight behind Kotlin, and the two offering a lot of the same features and
philosophy.

Does anyone know if the Scala maintainers have addressed this directly?

~~~
xvilka
Kotlin wins also because it has a stable and usable Native flavor. Scala
Native is a third-party project and seems dead, while Kotlin Native is the
core part of the Kotlin language and being developed at a fast pace.

~~~
vips7L
I don't think this is relevant since both languages compile to JVM bytecode
and Graal can compile that to native.

------
idclip
The problem with scala is that the docs were too late to come.

Those who put them out are geniuses (props Cats ppl, ZIO too) - but it seems
it is now too late. You know there’s irony that alot of the earlier docs were
based on haskell books, too.

Its not the math. Look at haskell’s freenode presense vs scala’s. Scala’s a
6th of haskell. What haskell had over scala is docs and community.

Scala was just too late, and my coworkers are all whispering Kotlin. It’s a
real shame.

Irony edit: i actually maintain a scala codebase at work, one of two under
thirty other devs who do, and me and one of the major players in the team were
talking about this only two days ago. Sort of a sad kind of funny.

~~~
stewbrew
The problem with scala is that academic goals sometimes don't align too well
with "industry needs".

~~~
hocuspocus
That's a complete myth, really. The Scala ecosystem has its fair share of
problems, but Odersky and his lab's involvement and stewardship have never
been one of them.

~~~
stewbrew
Just an example: Why wasn't it a priority to make scala run well on dalvik?
The place is taken by kotlin and is one of its strongest selling points.

~~~
oxnrtr
Core team didn't care about Android. Simple as that. :-)

~~~
stewbrew
That was pretty much my point.

------
walkingolof
For anyone curious about Scala 3 and its new significant indentation syntax, I
wrote a small Scala 3 project which also uses Graal native-image.

[https://github.com/olofwalker/ting](https://github.com/olofwalker/ting)

------
wffurr
Can we talk about this amazing gradual migration plan with code that can
coexist at the bytecode level across a major version change?

This is a real feat of engineering, and likely to make migration actually
happen and be fast and easy.

Compared to other 2 to 3 version changes, this is amazing.

------
wbillingsley
The complaints I see about Scala mostly seem to centre on whether _other_
people are adopting Scala. "Google's backing Kotlin", "Rust and Go have more
trajectory", "FP programmers in Scala write too complicated code that puts off
the OO developers", "FP programmers I know are moving to another language",
and of course the sad twitter-wars that seem to break out within the Scala
programming community that put people off.

Personally, I've found Scala to be by far the best language I've ever worked
with. The complaints on the complexity of the library are ones they are (at
least partially) trying to address in Scala 2.13. Dotty, though not
revolutionary, looks like a nice set of improvements too.

It's not a "pure FP language" (though some might like it to be), but is a
multi-paradigm language on the JVM. It has a lot in it, but moves relatively
slowly. To me, those are its advantages, and for someone like me they are
fantastic. I am in academia, which means that a lot of my software is written
by me for courses and so I get to work on it in patches about twice per year.
In Java-land, that'd mean major language versions are now faster than I get to
revisit my projects. In Scala, I've had projects progress from 2.10 to 2.13
(and soon 3) with maybe two days' effort updating them so they feel fresh with
the language, even though the language still feels more advanced than Java,
Kotlin, and most of the "faster" competitors.

Scala.js works astonishingly well (I wrote my own react-like framework in
about 1,000-lines of code, so I no longer need to fuss about whether React's
just updated so everyone should be using function hooks now either). Graal
looks like it's going to come along and solve the issues with native
deployment soon too.

In short, while most of the complaints I hear are about Scala as a community,
it seems one of its strengths is how it is _robust_ to the winds and storms
that blow through programming communities.

------
3dprintscanner
Having recently jumped into a Scala team from a mainly OOP background, I'm
starting to see the light with the language. Using the type system to handle
code you would otherwise have to write defensively. Letting the compiler take
more of the strain of the second order functional concerns of the program and
leaving what's left to be an accurate description of your problem domain is a
refreshing perspective on coding. Your code looks a lot more like the problem
you are trying to solve rather than 75% if(x==null) and 25% business logic.
That said, the learning curve is steep and the quasi-hidden nature of
implicits never sits well with me. It seems like a way of adding semi-defined
behavior to your code and is one of those language features that should be
treated with care.

------
AzzieElbab
Scala is an amazing programming language without rivals when it comes to
flexibility. Having said that, while I feel enormous respect for people who
pushed functional programming in scala to the limit and almost mainstream, I
think blindly porting 99% of Haskell to scala is largely responsible for
scalas's observed complexity.

------
aganame
I'm sorry to be this negative, but I sincerely believe Scala to be the worst
seriously used programming language of modern times. It should just end.

~~~
sgt
Why? This seems to be an uncommon opinion.

------
yahyaheee
Scala is dead for anything that isn't academic. They didn't listen to their
customers and ultimately burnt them. Every company I know that was using Scala
is running pretty much running any other direction now. It was an interesting
experiment I guess.

