
Scala 2.13 is now available - dtech
https://www.scala-lang.org/news/2.13.0
======
amzans
I work at a major online fashion aggregator and my team uses Scala extensively
for our search API (with Twitter's Finatra) and also in several of our data
pipeline systems (Akka, Spark).

When I joined a few years ago, I was honestly not most excited about working
with Scala, but the more I got into it, the more I realised that Scala got a
lot of things just right.

In particular, I really miss working with the collections and futures API
whenever I switch to another language.

And it's overall a pretty good package: very predictable behaviour, easy to
debug (IntelliJ Idea helps a lot here), fast runtime and high quality
libraries available for pretty much anything you might need.

~~~
skrebbel
I used Scala five-ish years ago, and I loved it, but I had two qualms:

1\. The community was terribly split between FP purists who wanted to write
Haskell on the JVM and pragmatists who leaned more towards the "better Java"
side of things. Plus the occasional ex-Rubyists who came up with method names
consisting solely of interpunction ("embedded DSL!"). Has any side won? It
would be nice to have anything resembling "idiomatic Scala" out there.

2\. The compilation times were horrid, really blocking a fast edit-compile-
run(-tests) loop, often making my attention wander away etc. Has this improved
sufficiently much that you can edit code, switch to the browser (or wherever)
and pretty much immediately see the result?

~~~
pas
I think there's a sensible middle ground.

Using types for side effects (eg Slick does it for DB IO) and error handling
(see also Rust's Result type) is great.

Scala's for-comprehension (which is Haskell's "do" notation) is a bit awkward
(you have to understand that it's a syntactic sugar, and you have to learn
about monad transformers, because you have to align the types, so if you
started with an Option you have to return an Option, so you have to wrap your
Futures and Lists, but it's pretty automatic).

There are a few things that seems harder if you are used to less pure
languages, let's say you can't just manage a request context "somewhere" and
rely on the dark arts of whatever Java (or Python's Flask) frameworks do. You
have to pass around a context. Use implicits. For async Scala already wants
you to pass around the execution context. And that's a good thing. Less black
magic is always nice in the long term.

Going full FP can be ... painful. When all you see is functions, functions
getting passed function, that return functions, that can be called with other
functions that ...

Yes, sure, in the end the data is passed/transformed/filtered/mapped/reduced
the same, but usually reading FP code is a lot less straightforward than it
should be. (For example nice chained functions / data-pipelines are great,
easy to read, etc. But going overboard with currying and function passing is
not.)

~~~
gridlockd
> Going full FP can be ... painful. When all you see is functions, functions
> getting passed function, that return functions, that can be called with
> other functions that ...

Exactly. "Functional purists" write code that caters to their aesthetics. It's
completely unreadable and a pain in the ass to debug, but it sure _looks_
really nice and clean.

If pure functional programming really is a major benefit, it should show in
the number of successful software projects. I don't see it.

------
dgellow
> We are delighted to announce the availability of Scala 2.13!

> The 2.13.0 release improves Scala in the following areas:

> \- Collections: Standard library collections have been overhauled for
> simplicity, performance, and safety. This is the centerpiece of the release.

> \- Standard library: Future is faster and more robust. Elsewhere, useful
> classes and methods have been added.

> \- Language: Literal types, partial unification, by-name implicits, more.

> \- Compiler: 5-10% faster, deterministic output, improved optimizer.

Full release note here:
[https://github.com/scala/scala/releases/tag/v2.13.0](https://github.com/scala/scala/releases/tag/v2.13.0)

------
lihaoyi
I personally really like how this release turned out. Tons of polish, cleanup,
simplification, and performance work.

Basically tackling the core problems with the language, with minimal feature
creep or additional complexity (I must admit to contributing to that creep in
a small way)

~~~
lmm
I guess there's always "one more feature", but to me it feels like Scala
stopped frustratingly _just_ short of getting the language design right.

Partial type application is frustratingly cumbersome. For the last 3 releases
or so - which is what, 6 years of language development? - people have been
using the kind-projector plugin to the point that it's now pretty much
entrenched. Any kind of built in solution - even if it were just bundling
kind-projector into the compiler - would have been better for the ecosystem in
terms of things like good compilation errors (which experienced users don't
notice, but can be a major pain for newcomers).

The situation for enums is even worse, with what must be a dozen competing
libraries/macros/..., none of which manages to be as nice as Java's "enum" (to
the extent that I actually write enums in Java when writing Scala). I get that
everyone has their own preferences, but even if the solution was just to adopt
the Java solution directly (but allow writing the body in Scala) that would be
a huge advance from where we currently are.

I love Scala but I really wish the developers had solved these two cases
before, effectively, freezing development of new language features for 5 years
and counting.

~~~
vvillena
Scala 3 (known in its prototype phase as Dotty) will solve lots of the issues
you describe. The language is reevaluating how some of its features are used
in practice, and lots of common use cases that now are a bit clunky will be
streamlined.

Other issues like better compiler errors and nicer tooling are being worked
on. Both Scala and SBT have advanced a lot on that regard, and I'm eager to
see what's next.

~~~
lmm
I'm aware. It was just frustrating to see two major releases (five years and
counting) focused on things that weren't an issue for me (indeed "Java 8
support" was actually a regression from my point of view, as it means my code
doesn't work on Android any more). At one point there was a fork that was
offering some more valuable features ("-Zirrefutable-patterns" was a huge help
in some of my code) which I would've wanted to try to contribute to, but then
it disappeared all of a sudden with all references to it vanishing, as if via
some back-room deal.

(It's possible that there's a better explanation in some of the meeting videos
that have started being published; in principle that's a great move,but I'm
not able to follow videos and there have never been any written
transcripts/minutes available (I have asked))

------
hszeeks
Extremely excited with the release!

I work at a fashion renting company and our backends are built on top of Scala
stack.

Contrary to popular belief, Scala is actually quite a simple language. Most of
our engineers came from PHP or Python, or Ruby and all have expressed how type
safety gave them great assurances that everything works if it compiles.

On top of that the behaviour of the language is very predictable! We almost
never use debugger because we can predict quite successfully what went wrong
in case of bugs.

Lagom was such a nice framework, coupled with Akka service discovery makes
building Event Sourced application so simple.

~~~
type0
To me this is possibly the biggest attraction, Scala feels solidly build and
still somehow manages to resemble the fun of using a scripting languages.

~~~
kamaal
As a matter of fact Scala and Clojure are every where were Perl was at one
point in time.

And for the same reasons.

~~~
vram22
What do you mean by "everywhere"? Business domains, or generally mean amount
of usage?

------
dotdi
The official announcement is quite an understatement. This release is big,
especially the changes to the collections standard library and compiler
performance will have a lot of positive impact overall.

Now onto 2.14 and Scala 3!

~~~
type0
I heard that some are fearmongering that Scala 3 will be as big of the change
like Perl 6 and as a result no one will ever use it. I'm not familiar with
dotty but somehow it doesn't make sense that Scala core devs would be stupid
enough to repeat the same mistakes that Perl did.

~~~
aphexairlines
A few differences between Scala2-to-3 and Perl5-to-6 or Python 2-to-3:

* Scala 2.14 and Scala 3 will be binary compatible (via an intermediate form called TASTY)

* The Scala 3.0 compiler will accept most Scala 2.14 source minus some deprecations that have been coming for a while

* Scala is a compiled language and a statically typed one at that, so any source incompatibility or library API incompatibility will be caught by the compiler; fix the issues pointed out and you're migrated.

~~~
lizmat
FWIW, The Perl 6 Module "Inline::Perl5" allows you to use __any __Perl 6
library inside Perl 6. After having installed "Inline::Perl5", you only need
to add ":from<Perl5>" to your -use- statement, e.g. "use
Benchmark:from<Perl5>".

------
type0
Why is Scala not more popular? It seems like such an awesome language, is it
because of it academic origins or because it's not functional enough?

~~~
mac01021
I've been turned off of it by SBT in the past.

~~~
aphexairlines
A lot of Java shops moved from Maven to Gradle, and Gradle builds Scala
projects:
[https://docs.gradle.org/current/userguide/scala_plugin.html](https://docs.gradle.org/current/userguide/scala_plugin.html)

Bazel works well too:
[https://github.com/bazelbuild/rules_scala](https://github.com/bazelbuild/rules_scala)

~~~
lmm
Maven itself works fine. In nine years of Scala I've never understood what
problem SBT is supposed to solve - it seems very complicated to no real
benefit.

~~~
swish_bob
I loved the incremental compile/watch tests stuff myself. It's been a while,
but I do miss having all my tests run every time I save a file.

But I do accept that sbt is not everybody's cup of tea.

~~~
lmm
I had heard that use case mentioned now that I think about it. To my mind it
makes much more sense to have the IDE handle that part; the IDE knows which
file I've edited and when I've saved it rather than having to scan the
filesystem. But I guess some people must find it useful.

------
namelosw
It's sad to see Kotlin took over quite a share from Scala in my perspective. A
lot of people are waiting for Scala 3 to make their decision which makes it
worse.

Don't get me wrong - Kotlin is a nice language. But Scala is one of the most
language to bring novel ideas in to the industry. There will be even dependent
type in Scala 3.

A lot of people are keep bashing languages like Scala for complexity. I don't
think they are wrong but in this way the industry is moving slow compared to
the reckless style in 90s. People are just too caution with new languages
nowadays, which makes things harder for new ones. New languages have to add a
lot of compromises to get attraction.

There's still a long way from carpentry to engineering.

------
nih0
Interesting that so many fashion companies use scala :)

~~~
dmit
And all of them are Zalando. =)

~~~
gtycomb
There may be something to what you say, speaking of newer generation fashion
busineess that try a newer technology. As an architect in this area during one
phase in my career, numerous fashion heavy weights ran SAP gobally. Oracle too
must have a good footprint.

------
AzzieElbab
Really liking this release. It trims off some confusing and redundant features
while making substantial improvements in scala's bread and butter blocks -
collections and futures. Type system changes are neat as well

------
kekepepe
We use Java in our projects and although there is interest in Scala, I fail to
see any real benefits from moving to it, especially with new Java features,
except for a nice addition to your CV.

Can anyone share their experience where moving from Scala to Java yielded
measurable benefits, besides "it's more fun to program in Scala"?

~~~
didibus
"More Fun" has more implications on productivity, defect rates, and quality
than you give it.

You can't underestimate how much the motivation of developers and their
enjoyment and engagement with a project, feature, or any given code change
actually impacts the overall delivery.

Now, if you don't find it more fun, more engaging and more motivating,
disregard this. But my point is, any language, tooling, environment, team
culture, etc., which will bring you "more fun" will actually make you deliver
way better software as a side effect.

------
SOLAR_FIELDS
> Standard library: Future is faster and more robust. Elsewhere, useful
> classes and methods have been added.

This is a pretty huge deal. Our backend API depends pretty much exclusively on
these, and everything is wrapped in them. Performance enhancements for these
will bubble into basically every Scala Play app.

