Scala 2.13 is now available | Hacker News Reader

Scala 2.13 is now available

scala-lang.org

130 pointsdtech85 comments

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.

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?

Compilation times have improved substantially: https://scala-ci.typesafe.com/grafana/dashboard/db/scala-ben...

2.13 seems to be a very marginal improvement over 2.12 so it seems to be business as usual re compilation.

Yes but I asked since 5 years ago, not since last release. Thanks aphexairlines, that's great to hear!

By that graph, 2.13 is 17% faster than 2.12. I'd call that more than marginal.

And as always with benchmarks, your workload may give you different results. 2.13 will especially help with code bases that heavily use the collections library.

Both IDEA/IntelliJ and sbt (probably both utilizing the same compiler library/features underneath) can do incremental compilation, which is very fast. (You get autocompletion suggestions in IDEA as you type, the reload-incrementalcompile cycle using Play is now spent mostly in spinning up the app after reload not in compilation, etc.)

Yes, compiling a ~200 file project from scratch takes ~5 minutes, but it has scalaz, shapeless and a ton of other libraries, but this is basically only required when you import/open the project for the first time.

actually all graphs are using projects that compile in under a minute. even the scala compiler is relativly small compared to average size scala projects. the gain is way bigger in projects that have clean compile times above 1 minute.

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

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

I don't think any side has won, but from what I gather Odersky thinks pragmatic functional is the way to go, i.e. only mutate when it brings substantial benefits to code clarity over a pure approach. That is, the default should always be functional, but use an imperative style where it makes sense.

This is my engineering org's philosophy as well. New engineers who have a java background tend to have some difficulty getting used to it, but all it takes is a light switch in their head.

For example, the other day there was a PR for creating a simple csv report and they wrote something like

  val buffer = new StringBuffer()
  buffer.add(header)
  buffer.add("\n")
  someList.forEach { item =>
    val values: List[String] = someTransformation(item)
    buffer.add(values.mkString(","))
    buffer.add("\n")
  }
  buffer.toString

which is fine and readable, but it doesn't really seem like having side-effects (even though the scope was contained in the function and there weren't any worries about thread safety) aren't worth it over doing something like

  val rows: List[String] = someList.map { item =>
    val values: List[String] = someTransformation(item)
    values.mkString(",")
  }
  (header :: rows).mkString("\n") + "\n" // I forgot whether they appended the string with a line break or not...

The above version might be more efficient (less allocations, less GC), which certainly matters for some applications.

I actually also find it more readable, but that’s a personal preference

I like that version A

1) is more readable (fight me)

2) doesn't rely on internal optimizations for string concatenation, in order to be as efficient

3) doesn't create extra garbage (linked lists)

In fact, the only thing I would change is make it a for loop instead.

You can have the line break appended at the end by using the three-arg version of mkString:

    (header :: rows).mkString("", "\n", "\n")

My two cents: I prefer the second solution. Maybe it's because I have never programmed in Java.

I love how when a person posts a good snippet someone will always chime in with an improvement

I would disagree that there isn’t idiomatic scala. Probably the most dominant style of programming scala is flatish class hierarchies with pure functions inherited and overrided as necessary.

In idiomatic example of this style is the ByteString library that is used by akka.

> 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

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)

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.

w.r.t. type lambdas and enums, AFAIK they’re working on it. See https://contributors.scala-lang.org/t/announcing-dotty-0-16-...

Scala seems to be lacking sponsors and contributors. Since 2018-01-01 according to GitHub only 44 people committed to scala/scala. (Which naturally follows a power-law distribution, so half of those people only have one or a few commits.)

And it's similar for the lampepfl/dotty repo (since 2018-01-01: 52 people, <10 active contributors) whereas the problem space is vast, the compiler is very intricate and brittle, the tasks at hand are many, and the language is complex, so trying any solution takes a lot of time and serious reviewing effort to try to make sure it doesn't cause any unintended problems.

And at the same time there are a lot of actively maintained libraries/frameworks/tools, but the overlap of the maintainers of those with the compiler maintainers is significant.

So all in all it's not surprising that things are not progressing super fast.

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.

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

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.

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.

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

And for the same reasons.

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

You mentioned PHP or Python, or Ruby devs. How was your experience on-boarding programmers with no Scala experience?

If you keep the Scala feature you use minimal, it should not get too complicated.

First step was to learn SBT, which in itself is simple (building projects, dependencies, plugins).

Later we have them do scala exercises (scala-exercises.org) to understand Scala basics, and the philosophy behind Scala, onboard on Framework (Play/Lagom).

Then we move on to Slick, and then Future API, error handling with Try, for yield comprehension, map and flatMap, collections, and of course implicits.

The rest would be comments on pull request.

>Contrary to popular belief, Scala is actually quite a simple language.

Interesting. Then why do some people say it is not? Anecdotal, mind you, and don't have links right now.

you are right, should have said "i think it is a simple language".

<edit>

what makes me think it is a simple language (especially if you are writing microservices):

- class is a class, and you don't really need to explain the modifier

- object is just an object, like if a class is instantiated, and it is a singleton

- trait gives you mixin, cake pattern / self type

- Future makes async programming simple

- for yield -> to avoid nested map / flatMap

- val for everything, instead of final static

- case class, such a life saver to build immutable data objects

Some libraries like Slick adds up complexity but the benefit i think far outweigh the difficulty of learning it.

Thanks for the answer. I had not heard of the cake pattern, will check it out.

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!

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.

Scala 2 and 3 are fundamentally the same language, which weakens the comparability to Perl5 => Perl6. The compiler is new and tooling will change but they do ensure Dotty can handle Scala 2 artifacts.

Scala already doesn't offer binary compatibility between major releases, which in itself is a bit cumbersome but it allows them to innovate the compiler. So the change will not be as drastic as it might look.

In addition, 2.14 is meant to be a release that eases the transition to Scala 3.

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.

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

There's a large amount of effort going into backwards compatibility.

Except for some really well motivated very advanced language features (eg view bounds) most code should be source compatible, and Scala 3/Dotty is able to use Scala 2 libraries and there's plans for forwards compatibility with Scala 2.14 (2.14 being able to use Scala 3 dependencies)

The big exception is macro's, because they depend heavily on Scala 2 compiler internals. A lot of things you require macro's in Scala 2 will become language features in 3, but for other cases the macro system for 3 is still in active development.

Scala 3 is all about baking common Scala patterns into the language, while making everything a bit nicer to use. It's an evolution and pretty much everyone in the Scala community is eager to adopt it. The fact that it will be binary-compatible with Scala 2.14 will make adoption much faster, too.

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?

There are well established programming languages for every single niche requirement. What's Scalas unique selling point? Where are they supposed to get/"steal" their users from?

Well the oblivious answer would be Java, but I get that my contempt for it is the only thing causing me to look at Scala and that's by no means universal as most people are pretty happy with the latest versions.

Well, it's the language of choice for Spark. That fills the big data niche.

At a concrete use case level, it's a language where you can write Java- or C#-like code with no "magic": no reflection, no AOP, none of the stuff that tends to be the biggest cause of bugs in real-world Java/C# codebases. All of the stuff that you would need reflection or AOP (or metaclasses or macros, in other languages) for, you can do in plain old Scala code.

In the abstract, it's the only mainstream language to offer both higher-kinded types and traditional OO ("extends") inheritance. From one side it offers all the good stuff of OCaml, F#, Swift, Kotlin, or Rust, but with a better type system that makes handling secondary concerns via "context-like" types a breeze. From the other side, it offers similar power to Haskell, but with more understandable performance, a better library/tool ecosystem (IDE, profiler and so on), less reliance on memory-unsafe code in practice (a lot of things in Haskell require C-wrapping libraries for things like image formats, whereas the corresponding cases in Scala wrap Java instead), and the ability to use traditional OO style if you want.

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

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

Bazel works well too: https://github.com/bazelbuild/rules_scala

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.

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.

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.

I have never fully understood why people are often upset with SBT.

Sure it is not perfect, but the alternatives are much worse and most of the issues people have with SBT projects are other people abusing the build file.

The REPL, fast incremental builds, continuous unit testing, shared SBT sessions, etc makes my day so much better.

I live all day long with: `~testOnly *WalabySpec -- -z killRoo`.

Whenever I have to jump into an app using Maven or only slightly better Gradle it is so frustrating.

I'm currently being turned off by SBT

Present (1.1+) SBT is much much nicer. It's the same core, but the new syntax does a great job of exposing what it does. It's still a complex tool, but it has become learnable.

Oh, and it's much faster nowadays.

Non-FP folks can hate on it because FP is confusing. FP folks can hate on it because it doesn't have pure functions. I don't believe the "best of both worlds" selling point.

Anyway I don't think it's worth dwelling on popularity. Networking and political effects seem to be more powerful than the merits of a language.

> I don't believe the "best of both worlds" selling point

Not best of both, but it's the ability to solve the task with either FP or OO depending on the task and do it seamlessly.

> Networking and political effects seem to be more powerful than the merits of a language.

That's probably more true than anything, also it's not hipster enough to convince your regular clojurescript aficionados.

From an outsider perspective (but my last company used Scala heavily), Scala supports nearly every language feature under the sun to the point that idiomatic use of the language is hard to define (unlike say Python, which has very strong idioms).

It seems that if you want a multi-paradigm language, Scala is excellent. But if you just want to go down the functional route or OO route (without overlap), there are arguably better choices.

It's because of the compiler and SBT to be frank. They are very very clunky.

You don't need SBT. Gradle builds Scala projects just fine.

Except Gradle is worst ...

Feel free to use Bazel or Pants or Mill or Maven or Fury if Gradle isn't your cup of tea.

Gradle is so much better than maven it's not even funny. Every time I check out a project in maven these days, I flinch.

Every time I get to do a Gradle build I have enough time to go out for lunch.

If true, I’m curious as to why. They call the same compiler and both support incremental compilation.

Because Gradle requires an additional daemon sucking up 2GB and uses Groovy for plenty of its tasks, instead of using declarative builds implemented in Java without using background daemons.

I seldom see conference talks how to optimize Maven builds, Gradle talks about build optimization, at least one per Java conference, and several per Android one.

Just Google IO 2019 had three talks about it.

That's just bizarre. And so far removed from my experience I'm genuinely surprised.

I've never had a gradle build that didn't manage to remember I've only just compiled the code and haven't changed any of it. I can't remember ever having a maven build that could tell I didn't need to compile every single time. And the same the whole of the way down the stack.

Nice attempt to imply gradle isn't declarative though.

Fortunately there are plenty of blog posts from Gradle blog and conference talks that prove otherwise.

Again just Google IO 2019 has three talks about tackling build performance issues.

Maven never required a build performance profiler tool.

Gradle is just like Ant, give DevOps a programming language DSL and they will make a mess of build scripts.

The compiler has gotten quite a bit faster since it started being measured.

See https://scala-ci.typesafe.com/grafana/dashboard/db/scala-ben...

Also SBT has been much less of a nuisance recently. They've made quite some effort to get rid of the most obscure syntax and with the recent improvements in compiler speed it's inching to 'acceptable' territory.

I admit that I really love the language, though.

The academic origins give the language a clarity that's great, at the same time macros and implicits and other language features make IDE support slow and error-prone and the compilation process as a whole rather slower than Java's or Kotlin's. On top of that, the designers introduce breaking changes in every minor release, which makes it a poor choice for software that you want to last very long.

All of these factors contributed to Scala adopters like LinkedIn subsequently retracing their steps and doing new development only in Java.

So, academic origins are fine (many good programming languages have academic or at least research-influenced origins), but an academic attitude to the development work that a language should support (predictability of breaking changes, possibility of good IDE support) harms the adoption of a language.

LinkedIn might also want cheap Java-labor. It’s one of the first languages you get in contact with after all.

Most of my background is in Python, but I've dabbled in a lot of languages out there from Haskell, lisp, Perl...etc. The point being I don't mind trying new things. I don't know Java and the JVM very well though and a lot of hosted languages like Scala, Clojure, Kotlin...etc seem to assume that you're intimately familiar with it which is a pain. Also, the Scala tooling when I last checked ~2 years ago was complex. I just wanted to write a simple app and started drowning in the complexity of SBT and gave up pretty quick. Your mileage may vary, especially if you're already familiar with the Java ecosystem. I've had more success with F# and OCaml.

Note that I'm not saying Scala is bad, it just wasn't an easy enough transition for me to justify climbing the plateau. Clojure ended up being a similar situation. These languages are also optimized around writing large software projects and that was a hindrance rather than a benefit to someone that does more scripting than anything.

Clojure is great for scripting now.

Does it still require you to magically know a ton of Java classes?

Nope.

Also many people are doing scripting on Node runtime instead of JVM.

Scala is only 15 years old. It's quite popular if you consider its age.

Sometimes Scala teams are more expensive to set up. So there are budget-friendlier alternatives (Java, PHP, Python, NodeJS) for many projects.

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.

Interesting that so many fashion companies use scala :)

fashion/media centers like NY have their own buzz even in technology. I remember back when Scala appeared, even Wall Street Journal running an article touting Scala as the next big happening in technology.

And all of them are Zalando. =)

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.

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

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"?

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

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

Reply on news.ycombinator.com