
What's Next for Scala - arbhassan
http://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala.html
======
seertaak
The Scala team pulled out all the stops with Dotty. It's a real tour de force,
on a par with the sea change of C++11. Even with the plaudits he's earned,
Martin Odersky is for me in the top three language designers of our time. (I'm
sure I'm being unfair to other members of his team with this comment, though.)

Dotty's union types are a thing of beauty, its implicits are really second to
none, and _so_ damn useful. Their decision to embrace whitespace sensitivity,
while simplifying the syntax for predominant use-cases (again, union types!)
betokens flexibility, and a desire to swing for the rafters.

The only thing that saddens me somewhat is that Scala Native does feel like a
bit of a second class citizen. The `stackalloc` feels a little sad (coming
from C++ -- it should be inverted!). I wonder if it's possible for Typesafe to
leverage Scala Native in a manner akin to Python with Numba/Cython. With
whitespace indentation - native code inlined and FFI'd automatically - right
there with the rest of the nice JVM stuff.

I can't resist citing my email from Feb '07 asking (politely) why we needed a
'new' keyword. Dotty apparently removes the need for that keyword. Should have
listened earlier, team Scala ;)

[http://www.scala-archive.org/quot-new-quot-keyword-
td1989540...](http://www.scala-archive.org/quot-new-quot-keyword-
td1989540.html)

~~~
erton23
Unfortunately, I slowly got frustrated reading the what's coming for Scala 3.

* True intersections and union types -- use them sometimes, not something you can't live without though.

* Trait parameters -- slightly easier life for OOP, ok I guess.

* Function types and implicit function types -- right, will make your code even harder to read (subjective).

* Generic tuples -- again, I can't remember we ever had problems with tuples in Scala.

* Opaque types -- another small OOP improvement.

* Type lambdas -- I've never seen them used.

* Erased parameters -- probably useful if it improves performance even at the cost of readability right?

* Enums -- finally something practical, good.

And that's all about major changes in Scala 3. Ah, yes, we get a new compiler.
Are you excited?

These changes look like a quarterly release than a major version shift. Now,
imagine a project manager who's estimating the migration downtime for Scala 2
for the sake of the above.

~~~
AheadOfTime295
Scala 3 could improve on 2.x struggles with supporting JDK 9 and up:

Support features of JDK 11+ [https://github.com/scala/scala-
dev/issues/139](https://github.com/scala/scala-dev/issues/139)

Support Java Module System [https://github.com/scala/scala-
dev/issues/529](https://github.com/scala/scala-dev/issues/529)

In comparison language features seem to attract much more attention:

Removing existential types [https://contributors.scala-lang.org/t/proposal-to-
remove-exi...](https://contributors.scala-lang.org/t/proposal-to-remove-
existential-types-from-the-language/2785)

Significant indentation syntax
[https://github.com/lampepfl/dotty/pull/7083](https://github.com/lampepfl/dotty/pull/7083)

~~~
pjmlp
That is a good example why betting on the platform languages is always a long
term safer bet than betting the house on guest languages,

Eventually they won't keep up with the underlying platform.

~~~
pas
It's not like it isn't working. Scala runs fine on JDK13 (probably 14 too, but
we currently run one Play project in prod on 13).

Java is a pretty safe bet, as it has an outstanding backward compatibility
track record.

------
lihaoyi
Author here. The full title is “The Death of Hype: What’s Next for Scala”, and
the full title is significant. This article is as much about the initial hype
and its decline as it is about the future prospects of the language. It very
much isn’t an official or even unofficial roadmap for the language, which is
what the shortened title makes it sound like.

~~~
arbhassan
I posted it with the original title. I don't know why the HN moderators almost
always change titles. Happened to me a couple of times.

------
jane_red
Scala is a beautiful and elegant language. I really thought that it would be
one of my favourite languages when I first started working with it. However,
after some time I got disenchanted. First, Scala is hard. Projects written by
one person quickly become a deep functional labyrinth and custom architectural
patterns because Scala is so expressive and you can do all kind of twists.
Second, the entrance level remains high. Your more experienced colleagues will
not allow to write anything that even remotely smells OOP. This delays the
time when you can be productive. Third, on paper Scala tries to serve both
object oriented and functional worlds but in practice the the latter is the
unconditional standard. Although I like the positive tone of the article, I
find it difficult to agree with Scala ever becoming mainstream.

~~~
mengibar10
I was asked to join a team of scala developers. Most except one had started
learning about 6 months earlier. I was asked to learn it while making small
contributions to the project. I quickly found out that there were statements
that could be interpreted in multiple ways, can't remember now what it was.
Then I got stuck on something and even our seasoned very enthusiastic Scala
developer could not solve it. I then and there decided not to pursue learning
the language and quickly have myself transferred to another team. It's a
difficult language, one should not spend thinking on the language but spend
time thinking about the problem itself. Probably what I say is not doing
justice to Scala as I was just a newbie but I did not have those problems with
Clojure which is another not that mainstream language.

~~~
jane_red
And that's the whole problem with Scala. When you work with it, you are having
a battle with types and compiler more often than you should. Funny but it is
not the first typed language I had to write code in. Never did I have to do so
much unnecessary dancing around and asking senior colleagues for help. I guess
not all of us are capable of grasping such expressiveness at the cost of such
complexity. The majority just need simpler tools to be productive.

~~~
pas
That's what led to ZIO.

Going full FP in Scala with Scalaz and "tagless final" (I still have no clear
idea what's that) and whatever else that's hip, leads to madness. Sure you can
write maximally polymorphic code. Great. But you end up doing the
extractions/refactors that the type system and the compiler allows, not those
that would help the code the most. Because those are too slow (too much boxing
and GC churn), or the compiler has a bug (or the library) so you end up
putting a TODO comment in the code with a link to a github issue.

Or it's a feature that's not supported by Scala, so you end up with a FP
spaghetti. :(

------
seahawks78
I very recently (about a year ago) joined a shop that is primarily into
functional programming (FP) and I got my first exposure to Scala as well as F#
through work projects. As a long time user of Java/OOP here are my thoughts on
Scala and why it has so many things things going against it. Consider the
following:

1) First, Scala is designed and developed by "ivory" tower academics primarily
for research/PhD thesis purposes. Nothing wrong with that. But that also means
language features are added not to solve a practical problem but mostly to
show that "it can be done"/"prove a point". When you are awake at 3 AM early
in the morning because a release made in the evening went awry and you are
trying to grep though logs/code to see what caused the issue I can assure you
that debates about "pure" versus "impure", Monads, Kleisli arrow will be
further from your mind. So the problem that Scala seems to suffer from is that
of "image".

2) Second, Scala is neither a fully functional (FP) nor object oriented (OOP).
Support for mixed/multi-paradigm sounds nice on paper but let me ask this
question: do you know of any hard core FP programmer who is excited about
inheritance or abstract classes or other OOP features? Vice-versa the same
thing can be said about many OOP programmers lukewarm response towards many
functional features of Scala. I believe that support for mixed/multiple
paradigms has hindered large scale adoption of Scala. The language seems to be
caught at cross-roads not knowing which way to advance next.

3) Third is lack of niche. True, I absolutely love "Spark" and primarily use
it to extract/manipulate data from HDFS/Hive storage but I am gradually
gravitating towards "Python" libraries due to their ease of use. What about
better Java? Kotlin check. What about sidecar systems used by DevOps? Go
check. What about a better designed system language? Rust check. The days of
pure general purpose programming languages are truly over and Scala will be in
great peril if it fails to expand into newer niches. Without broadening its
programmer base it will finally run out of people that can design newer
language features in light of ever advancing progresses in processor, OS and
memory architectures.

Just my two cents.

~~~
z6
Well put. I had to use Scala for a little and I wasn't a fan. It's maybe a fun
language to play around with for a pet project, but for a reliable production
system I would never pick it.

The language is too flexible with too many ways to do the same thing,
increasing cognitive load and making things difficult to understand. Maybe you
can limit that in your own projects, but what if you have to look at a library
codebase that's structured completely differently. Trying to understand that
can take a lot of time.

Also there is the problem with hiring. Maybe your current team can work well
with Scala, but what if a key member leaves or a service gets transferred.
Hiring for Scala turned out to be impossible, so you get all these people that
need to learn Scala first. Normally that may be ok, but Scala has a pretty
steep learning curve so it takes a lot longer to onboard people.

~~~
mchisto
On hiring: Python Paradox comes to mind
([http://www.paulgraham.com/pypar.html](http://www.paulgraham.com/pypar.html)).
I've never met sub-par FPer or Scala programmer specifically. Using PHP or
Javascript might give you a bigger top of the hiring funnel, but it doesn't
mean you'll have easier time finding well-qualified applicant.

------
zylepe
I’ve been using Scala as my main programming language for over 5 years. I’ve
found my “plateau of enlightenment” by sticking to a subset of the features:
case classes, for comprehensions, futures, immutability, pattern matching. By
avoiding things like implicit, overly complex types, defining/overloading
operators, and being dogmatic about FP/OOP I find the language stays out of
your way and lets you write code that reads like what you’re trying to do.

~~~
tormeh
I've done the same by being lazy, mainly treating it as a better Java and only
learning new stuff when necessary or obviously beneficial. I want to write
good programs, not fancy code.

My advice:

\- Options, immutability, pattern matching, and list comprehensions are all
awesome and better than the default Javaesque way

\- Scala concurrency abstractions all better than Java, but concurrency is
still hard. Proceed with caution

\-- Except parallel collections. Use those liberally

\- No Scalaz or any other FP-crusader stuff ever

\- Macros and implicits should be rejected by default in code review. Amazing
justifications required

\- Enforce coding rules with linters. This applies for any language, but
especially important for dynamic and non-straightjacket languages

~~~
jnbiche
OK, here's my question then. You're embracing Option type and yet presumably
avoiding monads, applicatives, and functors (avoiding "FP-crusader stuff"),
right?

So what happens when you are dealing with multiple option types, like you two
optional ints you need to add together? Or you have an optional field in an
optional object? This happens all the time in code that heavily uses Option
types.

So do you match on every one, and nest match expressions inside match
expressions inside match expressions? That can get very, very messy and even
confusing.

~~~
11Di
For comprehensions should alleviate the examples you have given with regards
to readability.

Although yes there are other more complex instances in which nested matches
might come up. Generally I would think to handle them by creating a function
that contains the next layer of matching instead of trying to come up with an
uber function. Adds a bit more verbosity perhaps but I find it is fairly easy
to follow and show intent.

~~~
jnbiche
My question was poorly phrased, since if you're using Option types, you're
obviously already using monads, applicatives, and functors.

What I should have asked was: if you're using monads such as Option, then how
do you use them effectively without using integral tools such as flatMap?

And you've answered: you can use for comprehensions. I primarily have used
Haskell and OCaml, so I sometimes forget about Scala's very nice for
comprehensions, which I agree is a great solution. But note that for
comprehensions are just syntactic sugar for `flatMap`.

I agree that if you do use Option types in Scala, for comprehensions are a
very elegant way to interact with them.

But I'll end with a question. If you're already using option types with for
comprehensions, why not also throw in other useful monads like bifunctor IO,
which is a great way to deal with async code? I understand the dislike for the
tendency in the FP Scala community to use custom sigils, but I do think most
people who are using options and for comprehensions would also be comfortable
and happy using other useful monads with for comprehensions.

~~~
hota_mazi
> but I do think most people who are using options and for comprehensions
> would also be comfortable and happy using other useful monads with for
> comprehensions.

You seem to vastly underestimate the gap there is between using a for
comprehension and understanding what a bifunctor is.

Nothing wrong with that: once you gain a certain advanced knowledge, it's
often very hard to put yourself in the shoes of someone who hasn't gained that
knowledge, and even harder to explain it to them in terms that they will
understand.

Which is why we have so many unhelpful monad tutorials.

------
totalperspectiv
As one of those new people boosting recent numbers, Scala is great! I use
vscode with Metals and had no jvm experience before. sbt is annoying, Mill
seems super promising, and graalvm native images basically mean that if I was
going to do it in python, I might as well use scala now.

~~~
walkingolof
Scala 3 have a Python feeling over it with optional braces indentation
([https://dotty.epfl.ch/docs/reference/other-new-
features/inde...](https://dotty.epfl.ch/docs/reference/other-new-
features/indentation.html))

I wrote an example using this new (optional syntax)
[https://github.com/olofwalker/ting](https://github.com/olofwalker/ting), if
anyone wants to have a look.

~~~
3fe9a03ccd14ca5
Maybe it’s just me, but “optional” is a word I hate seeing in language design,
because I’m thinking of how many code reviewers I’ve met that have a hard time
with “optional”.

------
zmmmmm
I've taken several passes at Scala but the thing that always stops me is that
I find it really hard to read unfamiliar code, including the core API
implementations. The only Scala code I find easy to read is impure semi-object
oriented code which is the non-idiomatic code that the Scala community tries
not to write. I'm not sure if there's some point at which a penny drops and it
all starts to become easy, but even if that is true, the time period it takes
for that to happen is a real hurdle for newcomers.

To me, you have to be intrinsically motivated to become productive in Scala
because of that early friction. Which is fine if you are, but if you're
looking at a team of programmers and thinking "how do I get them all over that
line" when about half of them have no intrinsic motivation to do that, it's a
real disincentive to use the language.

------
cutler
Scala faces tough competition from Kotlin which has two huge platforms -
Android and Spring/Pivotal. Arrow ([https://arrow-kt.io](https://arrow-
kt.io)), is enough to satisfy all but the most zealous FP purists whilst
maintaining first-class inter-op with the host language. I foresee a lot of
new projects adopting Kotlin where once they might have favoured Scala.

------
AheadOfTime295
For context see

Lightbend secures 25MM funding round, proceeds to layoff Scala contributors
[https://news.ycombinator.com/item?id=22842166](https://news.ycombinator.com/item?id=22842166)

~~~
marvy
I don't follow Scala (never wrote a single line), so I didn't realize the
company changed names from Typesafe to Lightbend. Here's a question: how on
earth do they make any money? The Wikipedia article makes an offhand mention
of something called Lightbend subscription; is that what keeps them afloat?

~~~
joshlemer
A lot of it is consulting, and they also have some proprietary and/or hosted
services, and even akka plugins that they charge for.

~~~
marvy
thanks

------
wiradikusuma
I love Scala! It's the language that enlightened me and be more productive.
Now, every time I code in other languages (e.g. Dart for Flutter, or JS for
web stuff), I grumble when I can't find "standard" features such as "map",
pattern matching, optional and named params, implicits.

Also, when I code in Scala, I frequently google and end up learning something
new about the language. I know it sounds like distraction/wasting time, but
there's a certain satisfaction when I found the "Scalaic" way of doing things,
like, "There's gotta be a one-liner way of doing this."

Of course, my complain is still compile time (yes it's significantly faster,
but I'm impatient).

~~~
erton23
You would be enlightened the same way or even more if you started with
Haskell. That is, it is not Scala you are so excited about but the functional
programming.

Btw, the actual thing to be inspired with in Scala is immutability and
Option/Some/None instead of null. These are the things that make you code
stable and reliable.

------
lcall
I wanted Scala to be my "better Java" for a long time, mainly because it
seemed to have plentiful headroom as I seek to learn more. The community
enthusiasm was also contagious.

But: 1) the ecosystem makes it seems like I need to be a genius enough to
learn a new DSL a bit too often, and everything is so...complex, which leads
to...

2) It is hard to pitch to an organization because of the learning curve if you
assume any project maintainer must learn scala to expert level. I failed (in
one attempt on a scala mailing list) to pitch to the scala community the idea
of having language levels: a compiler switch or the like that would guarantee
that a given project will be maintainable by java programmers with only N (1-2
I hope, for the first level) hours of scala training or study, maybe another
level for adding certain features (or listing them in a config file), and
full-on expert. So teams can be formed with realistic long-term
maintainability in mind. Edit: This may be practical with add-ons I didn't try
yet.

3) It was unclear what would be the best reasonable, maintainable way to use
sqlite. (Edit: in a multiplatform way to include at least BSD, linux, windows,
mac. Maybe call a native code library for each? Sounds like lots of work and
maintenance to do it well.)

4) Startup times, future viability of scala native (edit: or equivalent), and
whether it helps or adds enough more complexity given all the above, to just
learn Rust and (hopefully) simplify life (in some ways).

5) And you have to learn java first (for those who didn't know it already),
and know its libraries and idioms to some extent. Will that still likely be
true?

Comments welcome. (I enjoyed the article.) Maybe I'm just the type that wants
to hit the sweet spot between what C, Java, and Scala do (edit: and Scheme),
in a way that is hopefully/eventually at a complexity level that is inviting
to other devs, but with plenty of learning headroom for my future growth.

~~~
vvillena
Scala dev here. "Having to learn Java" is not true at all, unless you interact
with Java dependencies in special ways, or if you maintain a Java API for your
Scala code. There are Scala libraries for almost anything, and it's easy to
use some Java libs here and there. Creating wrappers is also simple.

One of the coolest things about Scala it that it already contains lots of Java
best practices. Case classes, singleton and companion objects, traits,
powerful generics... almost every Scala feature is a builtin answer for a Java
pattern. Hell, even implicits in all its various forms are elegant solutions
to common Java problems. People getting creative with these features is an
entirely different issue. It's possible, and desirable, to use Scala to craft
simple, elegant, and understandable code. Fancy but unmaintainable code should
not ever be accepted: it's the job of the developer to teach the reader what
the code does, and while this is true in any language, is more important when
coding Scala, because the multiparadigm approach means there are multiple ways
to solve things.

What you have to learn, at least in a basic form, is how the JVM works.

~~~
lcall
Thanks. I used Scala for some years and was always drawing on my java
knowledge. Are there now good scala learning materials that don't assume java
knowledge?

And the maintainability issue seems similar to perl vs. python in that way: it
can be done, but I've found it takes much more work and long-term attention &
presence, to enforce things with code reviews than with a project-level config
that everyone knows why it is there. Just once when you are not looking and
now you have a new (large or small) social and technical headache.

(Edit: in other words, while code reviews are essential I think for many
reasons, any time there is a way to enforce something good, before the review,
it seems like a win.)

~~~
vvillena
As for learning resources, I always loved the Oreilly "Programming Scala"
book:
[http://shop.oreilly.com/product/0636920033073.do](http://shop.oreilly.com/product/0636920033073.do)

It's one of the few books that is structured in the same way a Scala developer
thinks. Lots of Scala books follow the same order: keywords, usual syntax,
features also in Java, features exclusive to Scala. I think this is damaging
for any person looking to learn Scala, because it does nothing to lay out the
way the features interact together. for instance, the Oreilly book shows
pattern matching and implicits before class hierarchies, and that maps well
with how Scala devs work, because the former features are encountered daily,
while the latter tends to be uncommon.

As for maintainability: you're right. Stricter languages are more
maintainable. There's also the issue of powerful languages attracting certain
kinds of people. Over the years, I've settled on a simple policy: reject
everything that is not documented. This goes for both internal code, and
external dependencies.

------
3fe9a03ccd14ca5
Scala has the reputation of being fun to create stuff with, but horrendous
when understanding other people’s creations. Is this still true?

~~~
spir
It's less true now because some of the patterns associated with code that's
difficult to understand have been deprecated or flagged by the community to
avoid.

For example, implicit conversions are now disabled by default. It's possible
in Scala to pass a Foo to a function requiring a Bar due to a chain of
automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and
magical but difficult to understand and debug. The community and language
itself now suggests against this pattern.

Another example is that it's now (more or less) recognized within the
community that it's not preferable to dogmatically adhere to a particular
style of programming, such as pure functional or reactive/actors. It's better
to use the right tool for the right problem.

Whole classes of confusing code are now prevented or mitigated by language
changes in Scala 3. For example, Scala 2's implicits are famously hard to
learn and follow within a codebase. One reason for this is that in Scala 2 the
keyword "implicit" was overloaded into a few common patterns, including the
aforementioned implicit conversions, typeclass instances, and dependency
injection. Scala 3 introduces new constructs and keywords to split out these
patterns into separate language features, making them easier to learn and more
understandable within a codebase.

~~~
EdwardDiego
> For example, implicit conversions are now disabled by default. It's possible
> in Scala to pass a Foo to a function requiring a Bar due to a chain of
> automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and
> magical but difficult to understand and debug. The community and language
> itself now suggests against this pattern.

Oh God I'm having flashbacks to using Lift in... 2012? There were about four
levels of implicit conversions between my model and the final JSON, trying to
understand that was hard.

That said, David Pollak the founder of Liftweb was amazingly helpful on on
their mailing list.

------
fulafel
What's with the quote's casual Clojure dissing? Clojure seems more popular and
growing more than Scala, from where I sit. Kotlin is not eating into Clojure's
user base like Scala, which makes sense.

------
pjmlp
Since the post mentions Scala Native, all these guest language projects that
eschew the platform that made them famous and try to pursue the dream of being
their own platform, while building an ecosystem, GC and optimising compiler
from scratch (even if they build on LLVM or compile via C/C++), would be much
better taking advantage of AOT and JIT caches from several JVM implementations
instead of pretending they don't exist.

~~~
spir
In my mind, GraalVM native compilation has superseded scala-native.

GraalVM native compilation works really well. Many projects will compile to
native out of the box. Many more with a bit of reflection config that's
autogenerated. The native executables are slim, statically linked so they
"just work", and startup instantly as one would expect.

Scala is now a great choice for CLI tools.

~~~
tutanchamun
> statically linked so they "just work"

If I remember correctly you have to redistribute some .dll (VC something) file
alongside your .exe on Windows since fresh Windows installations don't have
the .dll. Did that change?

~~~
spir
I haven't tried GraalVM native-image on Windows :(

------
rethab
I'm particularly interested in how this plays out with dotty. My understanding
was that lightbend was at some going to take over that compiler from EPFL, but
taking over a compiler (the second, besides the current/old one) at the same
time they are laying people off?

~~~
AheadOfTime295
Announcement on Dotty as the future Scala 3 came from Scala Center (EPFL) not
Typesafe/Lightbend.

AFAIK Typesafe/Lightbend has made no commitment to Scala 3.

Too bad the roadmap for Scala 2.14 has been scrapped.

~~~
spir
I've worked with Dotty a bit and read about it a lot.

I am very excited about Scala 3 :)

Scala 3 isn't a python2/python3 situation. It will take years for large
codebases to be upgraded to Scala 3. However, the tools to migrate code from
Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's
strong type system. Most popular Scala libraries and frameworks will be
available on Scala 3 right from the get-go. I expect that most Scala
programmers and companies will want to write Scala 3 code asap.

Within the Scala community, the only truly divisive aspect of Scala 3 afaik is
the introduction of optional python-style and Haskell-style syntax with
significant whitespace. I was stridently against significant whitespace and
now prefer it after having tried coding Scala 3 for awhile.

~~~
jmeister
Thanks for this info, very useful and exciting.

I stopped using scala around 5 years back, want to get back to it. Would you
recommend jumping straight to dotty? I’ve been doing a mostly python and a bit
of Haskell in the meantime.

~~~
spir
I'd jump straight to dotty! You may as well learn the latest 'n greatest.

------
AheadOfTime295
Farewells piling up:

Six years at Lightbend, by Eugene Yokota (Scala sbt, scalaxb, scopt)
[https://news.ycombinator.com/item?id=22836399](https://news.ycombinator.com/item?id=22836399)

------
dkarl
I think a major reason Scala flourished was a big reason it has struggled as
well: it opened the doors for many people to new and fundamentally different
programming paradigms such as actor systems and functional programming. Many
people got excited and implemented these new paradigms in production systems
without regard to the immaturity of their own grasp of the concepts (think of
how many years of imperative/OO programming you had under your belt before
feeling confident of setting the style for a project), the learning curve they
were non-consensually committing their coworkers to, and the hiring,
productivity, and morale burden they were saddling their employers with. From
the management point of view, allowing Scala in the door meant running the
risk of waking up one day with a bunch of Scalaz in the codebase, one grinning
functional programmer happy as a pig in shit, and the rest of the team
shouting and cursing.

Likewise, on top of the real problems created by ill-conceived adoption, the
irrational backlash against new paradigms is real as well. I'm old enough to
remember the fuss over OO programming. Many experienced, successful coders
were scared that they were about to become personally obsolete. Some OO
proponents insinuated — and panicked veteran coders believed — that a large
number of procedural programmers would have to retire or switch careers
because they were too old or not intellectually nimble enough to adapt to
object-oriented programming. Major companies such as Sun responded to these
fears with a marketing blitz to prove their _their_ OO technology was simple
and easy to learn and would herald a new age of programmer productivity.
Programmer culture was more driven by magazines and books in those days and
therefore much more easily influenced by industry marketing. The "simplicity"
of Java was an invention of Sun marketing, a successful self-fulfilling
prophecy as Java became so familiar that similarity to it became millions of
programmers' benchmark of simplicity.

There has been no total war marketing blitz for functional or actor-based
programming from a company with the same stature that Sun had in the 1990s.
The emotional reaction, the resentment at feeling a step behind the future,
the anxiety about whether you will ever be as comfortable and confident in the
new paradigm, operate virtually in a vacuum, or worse, in the echo chamber of
the internet. Whatever latent fear of functional programming a person feels,
the prospect of using Scala will bring it to the fore. The only countervailing
force is the (usually lone) individual pushing adoption, and they are unlikely
to be up to the challenge. There is a tension between programmers who are more
oriented towards business problems, or who just want to get their job done and
go home, and the programmers who get excited about different and potentially
better ways to express programs. They both think of themselves as humble and
results-oriented and have a hard time accepting each other as being equally
humble and results-oriented in their own way. They both experience the other
as snobbish, condescending, and threatening to their self-image as good
engineers.

Sadly, the root of the problem is that Scala is expressive and powerful enough
to be a natural vehicle for these new paradigms. An engineering organization
should not fear expressive power, because they should have a culture that is
incompatible with a single engineer (or a small cabal) committing their peers
to a learning curve without consultation, debate over the cost and payoff, and
buy-in from the team. Unfortunately, there seems to be an assumption that
beyond choosing a language, you have no ability to consciously choose a style.
I.e., Scala-as-a-better-Java (the least imaginative approach, but not a bad
one) is an impossibility. This is grounded in the assumption that any aspect
of a language that can be abused, will be abused, and that engineers cannot
make collective decisions about how they will work together, which are odd
assumptions to make about the behavior of highly paid professionals. As
someone who wrote C++ professionally for many years, I can testify that it is
possible for engineers to conform to coding standards that restrict them to a
strict subset of the expressive power of a language. However, it sometimes
requires management authority to bring people in line -- and perhaps this is a
deal-breaker in an industry where teams of engineers are supposed to be
entirely self-managing.

------
dlandis
Scala is an awesome language and studying it helped me improve as a programmer
more than I can describe.

That being said, even though Haoyi said he doesn’t think Java has “caught up”,
the fact is it has closed the gap significantly on the language side, and will
always remain ahead in other ways (performance as one example). OpenJDK 14 is
an outstanding general purpose development platform, and the days are long
gone of anyone actually _needing_ an alternate JVM based language, whereas 10
years ago (or maybe even 5) there was a desperate need.

~~~
dkarl
If you think of it in terms of the words "need" and "alternative" then you
will find a reason not to use Scala. Personally, I have found it painful to
watch Java tack on Scala features years late and in awkward and clumsy ways.
Encountering ideas first in Scala and then in Java is too often like learning
math from a modern textbook and then looking at the same math in a textbook
from a hundred years ago. You appreciate how decades of small improvements
have made the subject less intellectually taxing despite the fundamental
content not changing at all. For Java to end up on the wrong side of this
comparison even when it implements features years later, to me marks it as a
language in terminal decline, no matter if its popularity has begun to reflect
it yet.

------
sandGorgon
> _Currently Scala is overwhelmingly used for backend services and /or Spark
> data pipelines,_

This is also being taken over by Python. Databricks Koalas is a pandas
interface on top of Spark -
[https://koalas.readthedocs.io/en/latest/](https://koalas.readthedocs.io/en/latest/)

PySpark was already there (and very much in production). But Koalas (in beta)
completely changes the go-to production aspects of spark.

------
tunesmith
I'm sad not because Scala is dying but because it will embolden the many loud
voices who like to proclaim it as dying, while others will believe them.
Meanwhile, it will continue to progress. I became a better java programmer, a
better php programmer, and a better javascript programmer by studying Scala. I
became better at distributed systems concepts by studying Akka. I'm sure I
will become better at a lot of other things by studying Akka Typed and Dotty.
It's a language that clarifies your thinking in a way that brings better
practices to other spheres. It's absolutely worth learning.

I've also had the experience of using it on undisciplined teams and that
sucked. One overly "clever" programmer can turn off a sufficient number of
other programmers and give it a bad rep. I don't think a language being
expressive is sufficient cause to blame the language for that, though.

------
trevyn
> _it seemed to peak around 2016_

[https://trends.google.com/trends/explore?cat=5&date=all&geo=...](https://trends.google.com/trends/explore?cat=5&date=all&geo=US&q=scala,golang,rust)

Early 2017, perhaps! Are Go and Rust seen as competitors to Scala?

~~~
ashtonkem
Depends who Scala was a competitor to.

If you viewed Scala as a competitor to Java, then Go is a competitor to Scala
and not Rust; because Go is a competitor to Java in my opinion.

~~~
pjmlp
Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants
to compete with Java 14 and its 25 years of tooling and libraries.

If Go 2.0 ever happens, it will be a competitor to Java 5.

~~~
ashtonkem
So, it depends on what you’re talking about; language or organizational need.

Go is an imperfect match for Java The language, largely because of the whole
Generics thing. But if you’re talking about how teams use Java and Go, they’re
a good match now.

Go was designed for large companies like Google to have a huge number of
engineers and produce consistent, quality code, all while constantly on
boarding people and moving them around. From an organizational perspective
there are a ton of Java shops that use Java for similar reasons, plus the
ability to cheaply and quickly acquire contractors who know Java.

~~~
pjmlp
Both, people comparing Go to Java apparently lack a complete understanding of
the Java universe.

If you are talking about doing REST APIs, talking to Postgres in Java 1.0
servlets style code, yeah Go is a replacement for Java.

Except that is like 1% of everything that is currently being done in Java.

------
_bxg1
> It's not Clojure-dead

What does this mean? I thought Clojure has a dedicated, if small, user base.

~~~
diggan
I guess in the authors mind, dead here means it's stable, solves its problems
well and doesn't try to attract developers with shiny new features but instead
focuses on enhancing the core experience which gets better.

As a Clojure/Script developer, I could understand that Clojure looks dead from
the outside if you're a JS developer, you're used to new language features
being shoehorned into the language every year.

But for someone inside the Clojure ecosystem who used to be a JS developer,
it's a breath of fresh air when I can take a 4 year old library and include
it, everything works and no bugs are to be found. If there is a bug, I can
patch it from the outside, if I really have to.

Clojure in general lends itself very well to be extended from the outside
(like what clojure.spec is currently doing [and many others]) so the core
language doesn't really have to change anymore, we're just building libraries
on top of the language which extends the language.

~~~
_bxg1
The dig at JS developers is completely uncalled-for.

I'm a JS developer and I admire the way Clojure has seemed to skip both the
hype and disillusionment phases and jump straight to the productivity plateau.

~~~
iLemming
> The dig at JS developers is completely uncalled-for.

Oh, no, as a developer who dealt with web front-ends for a long time, I can
attest - it is totally justified.

Modern Javascript, in just a matter of a few years from being a small, simple
language with a few quirks has blown into this colossal monstrosity.
ECMAScript specification today is almost as big as Java's. There are tons of
things that were added ( and still being added ) without careful thinking and
upfront design. And that not to mention things that break all the time in the
ecosystem of any JS framework. Have you ever tried updating dependencies in a
nodejs project that is just a few months old? It rarely is simple and
straightforward. Things break left and right. It feels there's no stability at
all, compared to Clojure(script) projects. You can pretty much pick any
Clojure project (that is a few years old) and update its dependencies, and
most of the time, you can expect things not to break.

People got excited about React hooks, and Clojurescript people were like:
"folks, we've had a better way of dealing with stateful components for a few
years now."

JS devs got excited about destructuring (which looks like a weak attempt to
borrow it from Clojure), without even slightest hint of how much more
straightforward and cooler destructuring actually looks and works in Clojure.

They say they love JSX, which, compared to Clojure's Hiccup, is just a total
and absolute crap.

JS devs are eager to use nulish coalescing and optional chaining and write
unreadable crap like: `input ?? obj?.key ? 'yes' : 'no'``. And they dare to
say that Lisps are not readable? ¯\\_(ツ)_/¯

Honestly, after years of dealing with it, my take on it is this: Javascript is
a morally outdated programming language. And Typescript is somewhat not the
best attempt to fix its issues.

~~~
beders
TypeScript adds that extra Java smell back into the mix ;)

------
brunojppb
Scala and the Play Framework became my tool belt for whatever web application
I need. It has all the batteries included, it’s stable and rock-solid. It
never felt so good to use a “boring” stack.

------
smabie
Hands down, Scala is my favorite language. The world-class type system
combined with its very practical nature make it a natural fit for really any
server backend. And now with GraalVM, Scala hopefully will make inroads into
desktop and command-line apps (start-up time has always been an issue, until
now). Scala 3 looks pretty amazing and the future is bright!

------
iLemming
> It's not Clojure-dead

It never ceases to amaze me. Almost every single time, whenever there's a post
or a comment on HN that mentions Clojure or Clojurescript, there's always
someone from outside of the Clojure community attacking the language, saying
things that are simply untrue. Like people are afraid of it becoming too
successful. It's not some zero-sum game - the success of one language
ecosystem doesn't mean that your other, the more favorite tool would be
immediately forgotten.

Somehow I don't see Clojure people attacking other languages; they instead
learn and borrow from them.

\- Python people would be like: "you can't do machine learning stuff...", and
what Clojure people say? Instead of fighting Python, they're like: "We can¹,
and also We have nothing against Python, we'll figure out a way to talk to it
from Clojure.²"

\- Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll
borrow it just the way how you did it. Also, we like Golang, we're going to
write a Clojure interpreter and linter in it.³"

\- R people: "Clojure is data-driven? Pfff... you know nothing about
statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured
out a way to interop from Clojure⁴."

\- Elixir people: "BEAM is way better than your JVM crap...", Clojure people:
"Not really, but okay, we see your point, we'll build Clojure on BEAM⁵"

\- JS/TS people say things like "Modern Javascript is so nice, who needs
Clojure now?" They get excited about stuff like React Hooks, and Clojure
people: "Hmmm... actually we had a better way of dealing with stateful UI
components for a few years now. We've been trying to tell you, but you never
listened..."

They've been saying, "Clojure is dead" for years now. But despite all the
odds, Clojure is very much alive and thriving. It's the most popular language
within languages with a strong FP emphasis. Just look around - it has more
books, more jobs, more podcasts, more conferences, and meetups than of
Haskell, OCaml, Purescript, Elm, Elixir, F#.

I suggest people from other PL communities learn from Clojure people. It is a
small but diverse and very friendly community of pragmatists - while others
keep shoveling the same shit from one corner to another, trying to re-invent
things over and over again, Clojurists keep borrowing good ideas and filtering
out bad ones. And calmly and quietly keep building cool stuff and getting paid
for it⁶.

¹ [https://dragan.rocks](https://dragan.rocks)

² [https://github.com/clj-python/libpython-clj](https://github.com/clj-
python/libpython-clj)

³ [https://github.com/candid82/joker](https://github.com/candid82/joker)

⁴ [https://github.com/scicloj/clojisr](https://github.com/scicloj/clojisr)

⁵ [https://github.com/clojerl/clojerl](https://github.com/clojerl/clojerl)

⁶ [https://bit.ly/3a3wxNH](https://bit.ly/3a3wxNH)

~~~
tutfbhuf
Hmm, I don't like the concept of talking about a programming community as e.g.
"python people" in combination with stating something on their behalf.

~~~
iLemming
You are absolutely right to correct me, I re-read my comment, and it does look
hypocritical, which wasn't my intent. Paradoxically, in the spotlight of what
you've said, it looks a bit like "bees against the honey" movement. After all,
I myself one of those "Python people." My lame excuse is that English is not
my first, second, or even third language. Choosing proper words and nicely
phrasing things in it ain't my forte, but I'm trying my best.

------
cutler
One of the most off-putting experiences when starting with Scala is the lack
of a dedicated Scala repository such as Clojars for Clojure. Floundering
around in Maven Central trying to get an idea of what's available for Scala is
an exercise in futility and enough to make you want to give-up before you've
even started.

~~~
sideeffffect
[https://index.scala-lang.org/](https://index.scala-lang.org/)

~~~
cutler
Great. I stand corrected. How long has that been up? Last time I started with
Scala it didn't exist.

~~~
maddening
More than 3 years. I've been using it for that long but it was pretty
functional and full even 3 years ago.

------
agumonkey
It is fun to see python being the beacon of friendly library design :)

------
lemiffe
Kotlin

------
snambi
Next Step for Scala: Shutdown.

