Hacker News new | past | comments | ask | show | jobs | submit login

Regarding LinkedIn, they are not moving away from Scala AFAIK. And Yammer was a long time ago. Note that Scala has improved quite a bit since then, especially with the release of 2.12.0 (Java 8 support).

I don't understand why, but there seems to be a lot of negativity aimed towards Scala. It's a solid language backed by the JVM, has great Java interop, and beautifully combines OOP and FP in a way I've never seen in any other language. Also, ScalaJS[1] is absolutely amazing.

Yet every few weeks, you get a blog post detailing why Scala is a failure and how it will be dead in a few years. Seriously, what gives?

[1]: https://www.scala-js.org/




I don't care much for language battles, but maybe I can shed some light on this.

The former VP of Platform Eng at Twitter said in 2015, "What I would have done differently four years ago is use Java and not used Scala as part of this rewrite. [...] it would take an engineer two months before they're fully productive and writing Scala code." The VP of Platform Eng at Twitter expressed regret for the choice of Scala.

LinkedIn's SVP of Eng Kevin Scott said, "We are not getting rid of Scala at LinkedIn. We've recently made the decision to minimize our dependence on Scala in our next generation front end infrastructure which is rolling out this year. We've also made a decision to focus our development infrastructure efforts on Java 8, Javascript, Objective-C, Swift, C++, and Python given the nature of things that we are building right now and will be building in the foreseeable future. That said, we have a ton of Scala code running in production, and will continue to provide basic support for Scala and those Scala systems for the foreseeable future."

And Coda's Yammer letter is around for those to Google.

Companies don't ditch languages that they have a huge investment in. It's just not worth it when you reach a certain level. It's not just the code to run your services, but the huge investment in performance, tooling, and monitoring - not to mention the bugs that come up from code that's just a little different. Twitter is past the scale where it can ditch a language. So is LinkedIn. But they can regret choices or decide to concentrate future development in a different direction.

I think that Java 8 has dulled some people's enthusiasm for Scala. Java 8 comes with a lot of nice features that people really missed in Java and might choose Scala because it did have them.

But I think more generally, there's been a movement away from being enamored with features, cleverness, and terse syntax in a language. Scala is a language of features, cleverness, and terse syntax. I was at a presentation by Rob Pike (one of the Go folk) and he argued that there are many things you can add to a language that feel clever and satisfying to write, but obscure what's actually going on and ultimately the things that are annoying, that are time sinks, and that cause problems aren't that you had to use a loop rather than something more clever. It was a long time ago so this is potentially more what I took away from the presentation than Pike's sentiment.

If we look at Go, Go is boring as hell. I mean, it has one cool thing in it - the goroutines (with cool being defined as something generally not found in all programming languages). It doesn't even have a lot of the cool things Java has. Java has annotations, inheritance, generics, a cool lambda syntax, "final" immutable references, advanced codegen. . . Go doesn't even have a way for me to declare an immutable variable. But it's so easy to pick up because there's basically nothing unfamiliar to someone who has experience with a mainstream, imperative language. Really, the syntax might be a bit different and it will always take a bit to adjust to a new language, but goroutines is really the only feature of the language that should be "new" to users (maybe multiple return vars, but that's stretching it). It generally emphasizes the ease of understanding and debugging over terseness of code. People seem to be enjoying that (at least some people). Part of it might just be that when a new philosophy comes onto the block, a lot more is written about it than gets written about old philosophies. For example, DHH just argued that Rails' all-in-one package is still a huge value add today, even though it doesn't get written about as much as it did a decade ago (https://www.quora.com/What-makes-Rails-a-framework-worth-lea...). It's possible that Scala's value add is as good as it once was, but the people who found that value add useful have long since stopped blogging about it.

I haven't used Scala that much. I like that it has a repl, I like immutability (which should be nice with Shenandoah GC), I like the fact that I can make a basic POJO (case class) without writing a novel of private fields, getters, setters, hash code, and equals. Scala definitely has some great parts that I wish Java had. Scala also has some hell that can make it harder to reason about (gratuitous operator overloading, implicits http://yz.mit.edu/wp/true-scala-complexity/).

Scala also came onto the scene at a time when Java didn't look so hot. Java 5/6 era Java (2004 & 2006) just didn't support the cool FP stuff that Scala did. Java 7 didn't come out until 2011 and still didn't have lambdas. It was 2014 before Java got a lambda. So Scala was this new language that ran on the JVM that had features! But maybe people didn't want all the features, but really only wanted a few of them like lambdas, streams, and the ability to make simple POJOs/case classes (which is still missing in Java, though things like http://immutables.github.io/ can help). I'm sure that there are many other reasons to use Scala. I'm not trying to argue anyone away from a language they enjoy using. The point I'm trying to make is that for many people, they might have chosen Scala for some of these simpler features that now mostly exist in Java. Other people might have been enamored with how productive that Scala made them at first and later decided that they were creating things that were harder to debug or for others to read and understand. Still others might not have realized that everything is terrible and there's no amazing new technology that's going to make them 100x happier than they used to be when they actually write real programs. Don't underestimate that last bit. Scala's been around and has plenty of people who have used it and not created anything in a shorter amount of time or more reliably than they had in Java, Python, or whatnot. . .but don't yet realize that everything is terrible. I'm not saying that languages don't matter. I think they do. Still, it's hard to find something that doesn't have huge terrible portions that will drive you nuts on occasion.

Scala isn't as shiny and new as it once was. A new language is always awesome before you have to debug what you write in it. Java 8 has implemented a lot of what people thought was missing from Java. People have dulled on "magic" (really just harder to follow code) that might be hard to discover how it works rather than easy-to-follow code. That doesn't mean Scala is terrible or anything, but it's advantage over Java is probably smaller for people who want some basic FP and the zeitgeist seems to be moving against languages that are more implicit or dynamic (regardless of whether that's happening in terms of LOC).


I think you hit on part of it which is that for a while Scala sold itself as a better java, and people ate that up, until they found out it wasn't.

Scala is not a better java, in fact it's a worse java (with better type inference). It has a worse IDE situation, compile times are slower, and it takes much longer to master.

Scala has been and continues to be my favorite language though, and I would absolutely use it for new projects along with building a company off of it if given the opportunity.

Scala's strength is not as a better java, but as a full fledged functional programming language that allows you to write pure, easily testable, easily parallelizable, robust software.

Rob Pike's statement is a reflection of the terrible mistake he makes by conflating application complexity with statement complexity. Any given line of Scala can absolutely be more terse and difficult to parse than a line of Go or C or Java, but that is often inversely proportional to the complexity of the entire application. Powerful languages mean less need for frameworks and less need for reinventing the same thing over and over. See Go/Generics for a microcosm of this idea.


All good points. Java 8 has captured a lot of things that people were missing, and new languages have sprung up that have tried to strike a good balance between terseness and complexity, with Kotlin currently being the new hotness in the JVM. Scala was in the right place at the right time, but its features lack orthoginality and coherency.


Which non-orthogonal and/or incoherent features do you have in mind?


I get this feeling when looking at the OO and functional styles continuously clashing. Implicit classes make some reasoning about functionality non-local. There's a horrendous amount of complexity in the OO side: case classes, traits, mixins, and a complex type hierarchy to boot.

Most languages just don't have that many features, and you could take different, non-overlapping subsets of features have something that could have an idiomatic style of its own and is good enough to solve most problems tersely.


Thing is, a lot of these nice things of Scala can you now get with Kotlin - with better IDE support, better readability, better compile times and more seamless interoperability with existing Java libraries.


Scala got a boost when it was just getting started by being a "Better Java". Now it's less able to stand on that value proposition and its losing supporters.

Honestly it was a great adoption strategy.


Thank you for taking the time to type up such a detailed response. I read through it more than once.

I agree with most of your points, but I still believe that Java != Scala, at least not yet. I think Scala still has a lot to offer that differentiates it from plain Java.


Not following Java very closely and using Scala as a better Java. Is there hope to get case-class POJOs in Java itself?


Project Lombok already does that, you should check it out: https://projectlombok.org/


Its scheduled for Java 9 or 10, not sure which.


Using another language that has tooling problems & slow compile speeds, I can understand why that alone would make you not want to use it anymore.

After a certain point all of the advantages of the ecosystem starts going away if compile/indexing speeds are not good and tooling doesn't work.

Golang was designed from the start to make tooling and fast compile speeds a first class citizen from the start. It has a lot of decisions that make sense when your working with large teams.


Compile times are a problem, yes, but tooling is not an issue. sbt is a solid build tool in my opinion.

Regarding the compiler, the Scala team has that as their number 1 priority right now. There is major work being done on building the compiler from the ground up [1]. Also, there is scala-native, which aims to provide AOT compilation for Scala code [2].

Scala vs. Go is an interesting comparison, but I think that they are each targeting different applications. There definitely is some overlap though. Go tooling is pretty good, but I don't see the hype. Maybe it becomes more clear if you're working on a large Go codebase? I don't know.

[1]: http://dotty.epfl.ch/

[2]: https://github.com/scala-native/scala-native


I come from the swift world, where a lot of their scala issues resonate with me. The article also mentioned tooling being an issue for them.

They have a lot of decisions that make a lot of sense in large code project context, which google has plenty of. Stuff like KISS, fast code speed, standard formatting & build tooling and so on.

I haven't worked with either language, so take what I say with a grain of salt.


What does it mean to make tooling a first class citizen?


From the start they decided to ship with a standard formatter / linter for example. A standard cross platform build system, optimized for build speed from the start, etc. I think a better word would of been a 'top priority'.


That is not a lot of tooling, actually. I am thinking about IDE integration, static analysis, code generation, package management. What are aspects of the tooling experience I am missing?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: