* The Mill build tool looks a lot better than SBT, but seems like everyone is still using SBT
* Scala minor version are binary incompatible, so maintaining Scala projects is a big pain. Upgrading Spark from Scala 2.11 to Scala 2.12 was a massive undertaking for example.
* Scala has tons of language features and lets people do crazy things in the code. Hard to win technical arguments with Scala geniuses that like using complicated language features.
* Scalatest is stil used by most projects and is annoying to use, as described here: https://github.com/lihaoyi/utest#why-utest. The overuse of DSLs in Scala is really annoying. Too many DSLs is another example of something I consider to be an antipattern, but there is no Scala community consensus on the responsible use of DSLs.
I'm optimistic about Scala. There are some folks that love the language and are continuously improving the ecosystem. Scala 3 will have to sell a better story about ditching legacy tooling and giving users a better default stack if it wants to compete with modern Go/Rust/Python.
Scala is a great language when Li Haoyi ecosystem of libraries is used. His libs do crazy Scala stuff under the hood, but expose a clean end user interface. The problem with Scala is that most ppl don't use his libs.
It's so annoying working on a Scala project with dependencies that all use different JSON libs.
Even new, awesome projects like Delta Lake still use Scala dependencies like Scalatest and SBT that should be replaced with Li's libs in my opinion (utest & Mill).
Scala could be an amazing ecosystem if the community unified around Li's libs. It just doesn't seem like that's going to happen. Li wrote the "whats wrong with SBT" article back in 2017 and it seems like everyone is still using SBT.
I wrote an article on the maintenance challenges with Scala projects that trended on HN a while back: https://mungingdata.com/scala/maintenance-nightmare-upgrade/. Li's libs would solve a lot of these issues cause most of them are intentionally dependency free.
It was frustrating for me to see how Li basically singlehandedly fixed the Scala library ecosystem, but how none of the projects I actually used depended on his libs. I ended up leaving Scala after several years even though I like the language when it's used a certain way.
Scala is such a powerful programming language that has so much potential to be mainstream, but it's just so abused by "genius programmers".
Only problem is the scala community is teeny tiny, tool support isn't there (There isn't an IDE with a scala plugin that fully supports scala), pure scala libraries tend to be unreadable and lack any solid documentation (looking at you scalaz, lift, and dispatch), and I think most importantly the scala compiler is SLOW.
I've written a bunch of production Scala code, and I'm glad to have gotten away from it. Obviously to each their own.
I totally agree. My main point against Scala is the mass of features, it's like a modern C++. In the worst case you end up with a dev team in which everyone codes in his very own style.
Quite a lot of shops choose not to use Scala because of the power. For instance, I can easily write Haskell-like code with Scala and build DSLs galore, which for me is great. But what happens when you need to hire more developers? That's the rub.
Other than the community and leadership issues mentioned in the article, Scala will never be enterprise ready because I can't think of a worse language for the enterprise. Large IT departments working on multi-MLOC codebases need a solid, clear language. Scala was promising back when it was meant to be "a better Java". And you know why people liked it? Mostly because it had lambdas and traits - two features that are in Java 8.
Since then, Scala has become a sort of a testbed for new ideas in compiler technology. Consider this – it's basically got three complete type systems: an OO, inheritance based type system, a Haskell-like algebraic type system (sealed traits and case classes), and a duck-typed type system (structural types). Each of these type systems has been enough to write good, complex software, on each own. Scala's got all three, while at the same time missing on all of their advantages. It doesn't have Haskell's type safety and purity (or type inference). It doesn't have OO's simple, highly extensible, and just-powerful-enough type system, because it's so big and complicated, and it doesn't have duck-typing's care-freedom, because it's so heavy. Oh, and it's got macros, too, just for the heck of it.
I know some people like it because they have fun writing lisp, Haskell, Java and JavaScript in the same file and have it compiled by just one compiler. Yeah, it's a cool compiler. But seriously, it doesn't offer anything enterprise would want. It doesn't offer safety; it doesn't offer simplicity; it doesn't offer familiarity. It doesn't even offer much compatibility: it's much harder to integrate Java with Scala than with Clojure or Groovy, let alone Kotlin.
And I'm willing to bet that almost all large companies that currently employ Scala, do it because of its original promise of being a better Java. But if you're a superset of about 4 language families, than you clearly can't a better Java.
For those who want that productivity boost while maintaining familiarity and compatibility, there's Kotlin. And Java 8, of course.
Scala is very powerful. Too powerful.
There are too many ways to do the same thing and no idiomatic way. Some people also abuse Scala to create DSLs with horrific syntax that is very hard to comprehend.
I love and use Scala, but I can totally see why it can
be a hard language to use for collaboration.
Scala developers end up on the defensive because many of the claims are either because of misunderstandings or are fashion driven, being repeated ad-nauseam many times by people with only a superficial experience of the language.
For example I'm going to make the claim that SBT indeed isn't just a bunch of symbols, but rather one of the best build management tools in existence. For anybody going to challenge that I'm going to start mentioning the complete clusterfuck of other platforms and languages, like that of C/C++, or that of Python, or that of Javascript, or that of C#/.NET, or that of Haskell. SBT not only does demonstrably a better job than most, but works well out of the box and is relatively pain free. It has its own set of problems of course, but what tool doesn't.
Compatibility issues are real. But you know, the nice thing about those compatibility issues is that it forced the community to come up with solutions. At least Scala and SBT are addressing compatibility issues, whereas the transition from Java 6 to later versions is proving to be next to impossible and I don't think I have to mention Python 3 or ECMAScript 6.
Compilation times haven't been that much of an issue for us because our codebase is split into services and libraries that have a reasonable size. And on the switch from Scala 2.10 to 2.11 I definitely saw an improvement, with the claims of 30% being about right.
I do agree that they can do better, taking a look at similar languages with a slightly better story, like Haskell. However what people are usually missing is that this is usually a trade-off with compile-time safety.
The more static a language is, the harder it is to compile it. The compilation cost for a dynamic language like Javascript is zero, the cost being completely amortized with everything happening directly at runtime. When going from Javascript to Java or C#, for people that prefer Java or C#, people go from zero to a very noticeable and resource intensive AOT compilation step and many times this tradeoff is worth it (depending on whom you ask) for safety, performance or tooling reasons. Well, Scala is a more static language than Java, it infers a lot of things, it has better generics, it does implicits which can then model type-classes and even the infamous CanBuildFrom pattern and so on, giving you a nice balance between productivity and safety in a static language. And that doesn't come for free.
Scala deserves all the hate. It might be a fun language for a throwaway pet project but I'd never recommend it in an enterprise setting.
It's an extremely unproductive language because it's too flexible. There are so many different ways to do the same thing which introduces unnecessary complexity.
I've used it for a while, and overall I love it. Easily my favorite language by a large margin I've been paid to use.
We use it exclusively on the server side at Verizon Labs, and it's quite beloved by all. We lean hard on the functional side of things and make heavy use of what some people call 'advanced features', but because of our micro services infrastructure even the teams new to Scala can be productive in a less functional style, and refactor later to be more idiomatic.
I do think large teams need to have enough language experts to help from making some bad design decisions, but I have plenty of productive coworkers who are new to the language and learning as they go.
I really don't agree about the 'maintainability fears' or 'write only' language criticisms. 'Bad' Scala is still so much better than bad java, and good scala is phenomenal to work with. Because of the type system, I have a high level of confidence when working with unfamiliar code and making minor changes.
Smart folks with no exposure to functional programming are picking up the 'advanced' features very quickly with the right training and guidance. I would not recommend it to a team who has on one with any experience in the language, but if a team can hire those who have experience with the language, even if it's just a fraction of the overall team, I'd be confident they could succeed.
There are real downsides:
* slow compile times
* IDEs can struggle with advanced libraries (Scalaz)
* some language features are 'sharp' (implicit conversions)
* finding developers who know scala
We're overcoming the first one by the fact that we're already a microservices shop.
The IDE issue doesn't affect me, I'm on Vim, many coworkers on Sublime/Ecmacs.
If you go crazy with implicit conversions it can cause issues, but again we try to mitigate this with some training and having enough advanced users of the language/code reviews to show everyone how to relegate using conversions for syntactic sugar or typeclass conversions.
People should be investing time in Scala (compiler and tooling, e.g. IDE support) instead of designing their own language that probably won't get a lot of traction.
Disclaimer : I'm nobody important, but I do have an opinion
If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem.
I used to write a lot of scala, and working with sbt was enough to eventually get under my skin.
I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract new learners, especially with just how overwhelming all the different features can seem for someone not coming from both sides. I had ocaml and ruby under my belt when I found scala, so it was an easier curve, but lots of guys struggle with it. I don't mind showing them, and of course I learn a lot from guys with different experiences and different backgrounds, but that's sometimes a complain I hear, also.
It's a language that doesn't compare very well. What is scala like? We don't know, there's only one language like it, it's a departure from many different paradigms.
I'm back to writing ocaml, all said and done. I enjoyed my time with scala, and interacting with my guys on the other side of the office still doing scala is always enjoyable. Smart guys! I'm not academic enough to grasp some of the new DOT stuff, but they are excited about it.
Anyways, I gave up hope a while back on scala getting rid of sbt. There are other build tools that exist, cbt, mill, maybe more, but without the blessing from lightbend or whatever they call themselves this week, it's not feasible, or responsible to deliver a solution to a client with an unofficial build setup. Of course, after five years of doing sbt I decided it's not ok to deliver sbt either.
In the Spark world, you can use a tiny subset of the Scala features and enjoy huge productivity gains over the other language APIs (Java & Python). Those productivity gains are wiped out as more crazy language features get used.
I don't think the super complex language features should be removed. Li's libs do some crazy stuff under the hood, but provide a clean, Python-like public interface. Most devs aren't that good and complex underlying implementations leak and yield complex public interfaces.
Lots of folks would love Scala codebases that only use 10% of the available language features and none of the complex frameworks. But, like you mentioned, it's a hard language to use responsibly.
I've been using Scala as my main development language since 2011. I came from a strong functional programming and C++ background, consequently learning Scala wasn't hard for me, and I find all claims about Scala's complexity overblown.
I'd say Scala, used pragmatically (e.g. avoiding advanced stuff like Shapeless or Scalaz), is currently the best mainstream programming language, meaning it offers the best compromise between language power, maturity of implementations and library eco-system.
My main criticism has always been the slow compiler which was eyewateringly terrible in 2011. With SBT's incremental compilation and faster machines the situation has become bearable.
> Your criteria make it impossible to use a language that came 'out of academia'.
Well, it would be silly to make such a broad, and hypothetical generalization, but as far as the "academic" languages I've seen, let's say a lot of caution is required before adoption in the industry. See my answer to tome.
> If you look at the top libraries/frameworks that are build on top of Scala...
While I can dispute your claim about most of the libraries you've mentioned, I can wholeheartedly agree that some Scala libraries provide much prettier APIs than Java libraries can. Still, the same can be said about C++ APIs vs. C APIs, and in spite of their elegance, a lot of large projects wish they had stuck with uglier C APIs, because most benefits come with costs attached. I'm not saying that Scala doesn't have any benefits -- it's got plenty. I'm just saying that in the case of Scala, its costs far outweigh its benefits.
The interesting question to me is, can we extract some of the goodness Scala brings without paying so dearly for it? The question is yet to be answered satisfactorily, but I think languages like Kotlin (or Swift, which, from what I've seen, looks very similar to Kotlin) show that this might indeed be possible.
About a decade ago, some Scala library authors thinking that "everything is better as a DSL" gave Scala a reputation for being a hieroglyphics soup, but that cannot be farther from the truth today. It's a really nice language to learn and to use, and the only one in my experience that I would want to take with me to scale from a quick dozen-liner script bash-style to a highly concurrent, highly available server application, from native to jvm to JS.
And the foothold in academics has some practical perks, too, like a sound type system (DOT calculus), compatibility guarantees at a theoretical level (TASTy), and what's cooking in the area of capture checking might be a general solution to many of the industry's biggest challenges (e.g. colorless asynchronous programming, safe errors, safe resource management, ... Think of Rust's borrow checker as a special case of this, and the consequences for scala-native as a systems programming platform).
1. Compile times. It is a problem for big projects. SBT / FSC helps quite a lot, but IMHO it is still not enough. I hope they get them much better in Scala 2.11. Also performance and correctness of the IDE plugin typechecking could be better, so I don't have to compile that often.
2. Lack of backwards binary compatibility. Source compatibility is ok, but selecting the right version of all the libraries is pretty painful, especially if the authors of the library didn't make the packages (yet) or they haven't been deployed to maven repo, etc.
3. That some elegant code constructs come with sometimes huge runtime performance penalty. It got much better recently (e.g. for loops are as fast as while loops now in Scala 2.10), but I feel it could be better. Again - hope Scala 2.11 addresses those concerns at least partially.
The things I don't agree with the OP:
1. Documentation - it is awesome.
2. Syntax flexibility - many times DSL is a better way of expressing things than just a bunch of methods, and easier to learn.
3. Tooling - good enough now, and improving fast.
4. Type inference - I consider it good enough, albeit not perfect. And types in method signatures add a lot to code readability.
There may be some languages that have better IDE support, faster compile times, better type inference, richer type system etc. But none of them supports full feature set of Scala, particularly all the available libraries. So IMHO taking every single feature out from Scala and comparing it let's say to Haskell or ML is ridiculous.
Who actually uses Scala.js, though? It still seems firmly in the hobbyist camp.
> One of main strengths of Scala is that people get things done.
This is also true of rust, go, c++, and arguably haskell. I don't see anything about scala that inherently makes it easier to "get things done". If anything, I've spent a good 10% of my scala development time (over hundreds if not thousands of hours) debugging library, compiler, and documentation bugs and inconsistencies. This is not good for a language where you get things done.
* Li's libs (os-lib, upickle, utest) have clean public interfaces, but most Scala ecosystem libs are hard to use, see the JSON alternatives for examples: https://www.lihaoyi.com/post/uJsonfastflexibleandintuitiveJS...
* The Mill build tool looks a lot better than SBT, but seems like everyone is still using SBT
* Scala minor version are binary incompatible, so maintaining Scala projects is a big pain. Upgrading Spark from Scala 2.11 to Scala 2.12 was a massive undertaking for example.
* Scala has tons of language features and lets people do crazy things in the code. Hard to win technical arguments with Scala geniuses that like using complicated language features.
* Scalatest is stil used by most projects and is annoying to use, as described here: https://github.com/lihaoyi/utest#why-utest. The overuse of DSLs in Scala is really annoying. Too many DSLs is another example of something I consider to be an antipattern, but there is no Scala community consensus on the responsible use of DSLs.
I'm optimistic about Scala. There are some folks that love the language and are continuously improving the ecosystem. Scala 3 will have to sell a better story about ditching legacy tooling and giving users a better default stack if it wants to compete with modern Go/Rust/Python.
reply