Interesting article, although I disagree with the sub-title “And it Still Could”: Scala is in an irreversible decline.
None of the problems Scala faces are new; if there was willingness to fix them, they would have been fixed years ago.
Instead, the language has been bleeding out for a long time already; both in quantity (since Kotlin was released), and quality (good luck getting competent external contributors with Scala’s reputation of treating people).
good luck getting competent external contributors with Scala’s reputation of treating people
And if you get past that, the Scala compiler’s code is considered a massive mess by most people who have worked on it. Things that seem functional but are actually backed by weird mutation at distance. I had hope that Dotty would be better, but it somehow followed the exact same patterns the original did!
I did quite a lot of Scala work at GettyImages and introduced it in a Java team for a telecom company, plus I maintain an open source project (bigsense.io) written in Scala as well.
There is still industry use, my city has a Scala meetup and there are companies here that use Scala … that being said; I’m currently working in a Clojure shop (doing devops, so I don’t really touch/can’t compare Clojure).
Yet .. all the points this article brings up are totally true. I hate the abuse over operator overloading and implicites to make DSLs. Seriously, just keep it all consistent Scala instead of making your own language. I don’t want to learn your weird operators. Half of the Scala libraries just seems like they’re duck tape for converting between types. The core language is alright, but a ton of libraries out there can get insanely complex.
Also, SBT can go die in a fire. The crazy macro expansion and other limitations make it difficult to do a lot of common multi-stage build steps. Opening up the source code will make you want to stab yourself in the eye with an ice pick. On newer projects I tend to just use gradle with Scala .. which has its own interesting problems (most around tutorials exclusively having instructions for SBT that don’t work with any other build tool).
I’ve always wondered why Scala has introduced SBT instead of using regular Gradle? It seems it does exactly the same kind of job that Gradle is designed to do, where Gradle is used by more people and is older?
There are some Scala specific things you can do with SBT which I’m not sure if you can implement in Gradle. sbt console builds you a REPL against your current code base and all dependencies so you can try thing out live. sbt ~console is the same with hot code rebuilds.
Although after doing a search, it looks like someone found a solution:
The changes in Scala 3 are so dramatic that all Scala developers will need to be re-trained and all codebases will need to undergo a migration.
Is there any source to support such claim? I briefly looked at Dotty’s website but apart from a few dropped features didn’t find anything that alarming.
It’s worth emphasizing that Scala 2 and Scala 3 are fundamentally the same language. The compiler is new, but nearly everything Scala programmers already know about Scala 2 applies to Scala 3 as well, and most ordinary Scala 2 code will also work on Scala 3 with only minor changes.
Heck, further down he even claimed that it’d be possible to use Scala 2 artifacts, use -language:Scala2 option that “lets it compile most Scala 2 code and at the same time highlights necessary rewritings as migration warnings” or even that “compiler can perform many of the rewritings automatically using a -rewrite option”.
My judging is that the tone of the article was unnecesarily dramatic and unless some crucial information is hidden from project’s website and Odersky’s blogpost, I really do understand why Scala dev’s would perceive it as toxic trolling or FUD. It’s generally good to avoid overly emotional people who fail to disclose sources for their statements.
Scala devs have mastered the ability to promise things and then do a switcheroo and reinterpret what they said in the most restrictive way until they can claim they “never said that”. Also, claiming that things one doesn’t like hearing are “toxic” or “FUD” is Scala community management 101.
Like when they tried to make it appear as if Scala 3 was a smaller, simpler language, when it’s painfully obvious that it’s not true. I’m just waiting for them to claim “that this was only talking about our (useless) DOT calculus, people must have misunderstood us!”.
Speaking from my personal experience, Martin saying $thing does not convey whether they are in fact true or not, only that saying $thing was most convenient at that point in time.
All I ask for is some evidence. I could easily go and make ill-minded fake accusations about virtually any project and, provided the community is large enough, there would probably be a handful of people agreeing with me. I’m definitely not saying that’s the case here, but at the same time would much rather construct my own opinion instead of just adopting one.
It all boils down to providing some verifiable statements – most preferrably with sources. After making sure these statements are correct (or at least probably correct, depending on how much I care), I can make my own judgement.
Since I didn’t get a single example of “a dramatic change” that would require “all Scala developers to be retrained and all codebase to undergo a migration”, I tried to search them up myself. What I found seems incompatible with Scala 2, but not really “dramatic” and recquiring a complete retraining.
Now you are saying that Martin Odersky is not trustworthy – again without a single example that I could look up and verify. Since Odersky isn’t the one starting the emotional battle here and I value him for his previous work, I trust him more.
So far the only thing I learned is that some people have negative feelings about Scala and its community. To convince me to join them, it’d take a whole lot more than that.
PS: I learned a little bit of Scala a while back and always thought it was an interesting and in a way a really nice language, but at the same time was somewhat sceptical about using it for larger projects. I generally tend to think that overly complex languages are a source of pain in a team work.
Speaking from my personal experience, Martin saying $thing does not convey whether they are in fact true or not, only that saying $thing was most convenient at that point in time.
I have a hard time in figuring out what the problem is? Obviously, it’s not unusual to say different things on different occasions, in several levels of detail. Or things may have been true in the past, but are not now. Are you saying that Martin actively says wrong things?
I once tried to talk to him about wanting to work on improving the Scala websites’ documentation for beginners. His response was that it wasn’t necessary because “everyone already knows Scala”.
After multiple other efforts and offers to help I announced that would give up trying to improve the website if nobody cared.
That’s when he suddenly claimed that he was happy to receive contributions.
This caused me to leave Scala, because I’m not willing to be gas lighted in front of a thousand people, and it’s frankly not my problem that he says different things in private and public.
Then there was the time where he sent an emotional email to my university’s dean about some non-existing thesis, others have spilled some of the beans here.
It’s interesting to see compile-time framed as if it were a tooling issue. Language design affects it deeply. Go will be fast no matter what. Languages like Scala and C++ have some features that are inherently costly. At that point, the real gains come from providing guidance about what features/dependency structures to avoid.
Is there anything reasonably in-depth written on why it’s faster? It seems implausible that it’s entirely due to just being a really good compiler and 100% unrelated to the design of D as a language. Two heuristic reasons to guess that there must be some relationship: 1) the primary D designer was also the primary compiler implementer with a long history of compiler implementation, so seems likely to have been at least somewhat influenced in his design of D by implementation concerns, and 2) nobody has written a fast C++ compiler, despite there being a big market there (certainly bigger than the market for a fast D compiler). I could be wrong though!
I’d like to see more detail about the claims that the scala dev team are weaponizing the Code of Conduct to suppress criticism of technical decisions and the no-platforming of a prominent contributor.
I found the first sections of the article quite reasonable, but in the end when the author suggested one visit a subreddit other than the official one left me with a feeling he has an axe to grind.
The Scala community has had lots of ugly little spats. People have been banned from the /r/scala reddit, from the {users,contributors}.scala-lang.org discussion forums, and even projects have been pulled from the Lightbend (formerly known as Scala) community build server which checks compiler compatibility against popular projects. This is just the most recent stuff off the top of my head. Plenty of earlier contributors have left, some with some public hard feelings, others quietly. If you’re not part of the community, be thankful and move on is all I can say. There’s no need for you to go down the rabbit hole of this petty drama.
You have people telling you their experience, if you don’t believe them, no amount of stuff is going to change that.
Supporting evidence has a way of, um, supporting an opinion.
I think all the Scala contributors who have left are sick and tired of having to prove their innocence and being held to higher standards than the people dishing out the harassment.
Your reaction might be appropriate if I were a supporter of the Scala party line who was sealioning you, but I am not a part of the Scala community and have not really been watching this happen very closely. I knew about Scala 3/Dotty but not all the interpersonal stuff this article mentions. I think most of the posters here are in the same boat as me. So rather than whine about having to point to some, any evidence about the assertions the article makes and you seem to support, make both of our lives easier and show me something.
Otherwise this is all hearsay, and we the uninformed readers are left choosing one side or another to place faith in. Faith is trust without evidence, and I’d like to avoid that.
I’d like to see exactly what claims were suppressed as violating the CoC and what the dev team’s stated justification for treating them as such was. I’d like to see what the person who was no-platformed said that made the dev team think no-platforming was warranted.
I find it very odd to see “Python3 and Perl6” in one sentence. Python3 has succeeded despite the mismanaged transition—but it’s also far less of a dramatic change than Perl6. Not sure about Scala 3, I haven’t looked.
Legacy systems are the norm. The new one runs in parallel instead of replacing the old one given its many users and investment. That both are doing well is probably a good thing in light of this.
Sure. Which is why python 2 ceasing to receive even security patches is going to prompt some responses.
We’re either going to see pushes to migrate (what guido and the python dev gang expect) or some efforts to continue running those python2 codebases with security patches (maybe a switch to pypy and continued community support of that project). The latter has the potential to reshape the politics of the python community.
“dev gang” sounds weird? Is that really a term that is used in the python community?
The Ruby community has found solutions to that. There’s specialised agencies keeping old codebases secure for old Rails and Ruby versions against reasonable fees. It’s infeasible for community maintainers to support legacy.
On the other hand, as rough as it was, the MRI team has also made sure that there’s feasible migration paths, so that you can make a reasonable decision whether to put money/effort into migration or paid maintenance.
I see “python-dev” used pretty frequently in the Python community to refer to the language developers (as distinct from library developers or the wider community) — it’s a reference to this mailing list.
The question is really about who’ll be providing the support. There is no question in my mind that there will be Python 2 updates following the drop dead date for support. The question is whether the Python core team will decide to push the updates, have support forked by another community, or whether vendors (ActiveState, RedHat, etc.) will be the ones driving the support. The thinking seems to be that it’ll be the latter since open source projects have much less reason to get stuck than companies. That said, I’m sure the Python core team would consider pushing an update for some critical (security) issue, if it was decided in the best interests of the community and industry. I doubt that scenario will arise though, but it’s a possibility for a well run and organized community to consider.
Where does your understanding of Guido’s expectations come from? I’ve been present at all PyCons since 2008, except two in recent years. I’ve never seen explicit expectations like the ones you describe from Guido, or others in leadership positions. They have been pretty pragmatic with their understanding of how any Python 2 to 3 migration will happen with an understanding that eventually it’ll make sense to sunset Python 2. The wider Python and online communities however have understood or listened to little of what has been said. That extends to async, and many other developments in the language/runtime over the past decade.
I used Scala a bunch at Apple, and then my current teams use it. I really find it grating, for the same reason I find C++ grating – it is just a giant pile of stuff without a clear through-line, and it encourages all kinds of nasty shorthand. It is almost perfectly designed to irritate me, but since I’m just a Mr Manager Person now, and no longer expected to generate it, I can accede to my team’s desire to use it.
But I’d never recommend that anyone start a new project with it.
This is true, yes. I am comfortable with the team’s usage of Scala (lots and lots of Spark), and the team is comfortable with the insanity. I just stay the F. away.
Ah, Spark is one of those nagging reasons to use Scala that’s hard to avoid when you need it. You have my sympathies. Please try to maintain space for the non-Haskell developers on your team, or you may find them running for the exits before too long. Speaking from experience.
Yeah, it’s sort of the lingua franca. Happily, my people are more into Spark than they are into Scala, so I’m not that worried that some of the horror will creep in.
To address some of the author’s complaints — when judging from the lens of other languages and ecosystems — and note that I refer to Haskell, because it is the author’s current favorite programing language …
Compilation times are a problem, especially for libraries where macros are involved
I hope Dotty will solve this; that said the compiler works pretty well, compared with a language like Haskell — maybe it’s because the dependencies are distributed as binaries, but I always hate compiling Haskell projects, whereas Scala is bearable
In my experience Scala compile times are OK, however if you experience issues, the best thing you can do is to split your project in sub-projects, thus forcing a clear separation between modules — if a library like Shapeless becomes a problem, then the parts that depend on Shapeless should be in their own module
that Twitter is building their own compiler is pretty cool, however note that companies like Google, Facebook and Twitter operate at a scale that makes any compiler problematic, especially when they have monorepos
if anything that Twitter is working on this is great, it means we might get something really good out of it
Tooling for Scala is in my opinion, great and I have much experience with many other ecosystems, including Java, Node.js/JavaScript, Python, Ruby, Perl, .NET and Haskell
IntelliJ IDEA is the best IDE available on the market and the Scala plugin is made by Jetbrains and has their quality standards
other ecosystems can only dream of such support 😉 just to give an example, all Haskell IDEs (plugins for IntelliJ IDEA, VS Code, Emacs, etc) are unusable, the only reasonable option for Haskell is ghci and ghcid (which is basically sbt console and sbt ~compile respectively), everything else sucks
Scala’s sbt is one of the best build tools available — you get incremental compilation, continuous testing, dependency management, a REPL and tons of plugins for most tasks you have in one package; its syntax can surely be better and some of the plugins would need better maintenance, however overall I miss sbt whenever I’m building projects for anything non-Scala
It is regrettable that Ensime was deprecated and if Metals isn’t used, that’s a shame too — note however that other languages, like F# and C#, have official tooling and LSP server integration in their organization; I do hope they’ll reuse the work from Metals
On the other hand, everything that comes out of Scala Center is free work for us and if you don’t like what they do, then you can always roll your sleeves and provide a competing alternative
It is indeed hard to hire Scala developers, but have you ever tried hiring Java developers that have some knowledge of multi-threading and asynchrony concerns?
Hiring good developers is not easy at all. Also one mistake that people make is to hire Java developers and then retrain them for Scala. I think this is a mistake …
Hire Node.js / TypeScript developers instead. JavaScript developers tend to be familiar with the style of functional programming practiced in Scala — too bad they write quite shitty code due to their dynamic typing roots — but you can filter those out by selecting for TypeScript experience. I now believe that Node.js + TypeScript devs are better candidates. And that’s not the only pool you can search in.
The real problem are the concepts involved, which aren’t at all easy to grok:
higher order functions
immutability, persistent collections
not working with null
signaling errors via types instead of exceptions
map and flatMap everywhere
implicits
type classes
higher kinded types
macros
if you’re super unlucky: working with untyped actors, especially ones that have shared state
The more you go down this path, the WTFs per minute increase exponentially. As you read this list, you should realize this isn’t about the language at all, but about its functional programming culture. It’s in fact much harder to hire for languages like Haskell. The more you diverge from the mainstream practices, the harder it is to hire. That’s why Go, like PHP before it, is a raging success
Java hasn’t caught up in any meaningful sense.
And that’s in fact a problem, because the pool of Java developers familiar with basic FP concepts is very small, which is one reason for why we’ve got an inability to hire people. I’m now more inclined to hire from pools where devs are familiar with basic FP concepts.
I want Java to catch up, just a little would go a long way. It doesn’t and anybody that watched Java’s evolution should know that the language has been historically super conservative, all meaningful improvements going into the runtime and I don’t see that changing. Many people have been screaming for C#’s features since 2001 at least.
Scala 3 is going to be a great release. The reasons why I like Scala 3:
cleans up macros — which is great, because macros are the main reason for why Scala is hard to learn by beginners
simplifies implicits
makes typeclasses natural, introduces derivation — this should address the author’s main concerns with libraries like Shapeless
adds untagged union types — just like what you have in TypeScript
might express nullables via unions — we already use Option, but this is a tagged type; having the ability to express nulls via the type system is great, because it reduces the accidents
adds enums (nicer syntax for ADTs)
GADTs are now supported
This is a list of features that simplify the language and if there’s breakage involved, then it’s worth it.
Also Scala 2.14 binaries are going to be binary compatible with Scala 3. This is not the same situation as with Python 3.
In your career it’s important to not get bitter — tools are tools. If a tool stops working for you and you can’t invest in that ecosystem anymore, then simply move on.
And criticism should be welcome, but make it constructive. This article contains criticism that’s not constructive. Nonconstructive criticism isn’t criticism you make in the hope of changing things and it leads to anger and resentment, both for you and your readers.
Curious. I’ve really enjoyed working with Scala and I consider it a really nice language. I would love to do 100% of my work in Scala again (prior project/company was heavy Scala). I do agree shapeless is weird.
I also wonder about shops who hire exclusively for specific tooling on top of a language (Play, Akka, etc). That seems spectacularly dumb, and no shop I’ve worked at has even floated that as a thing to possible hire for - and I’ve been involved in hiring discussions for the last decade or so. Is that a thing outside of consultancy hiring?
This has been my general feeling with Scala. I have worked through some Scala books 2008-2012 and wrote some Scala programs for internal use. I also encountered quite a lot of student-submitted Scala code in one of my courses a few years back, because a colleague had taught a Scala seminar. To me Scala resembled C++: a lot of accidental complexity, trying to be everything to everybody, and long build times without the main benefit of C++, namely performance. I think the only minor benefit was that gives access to JVM ecosystem (if you need that), but for the people who just wanted a better Java there is Kotlin and Java >= 8 now.
The only sad thing is that – when only looking at the common language subset shared between Kotlin and Scala – Scala is substantially better than Kotlin.
I’m back to Java, and simply stopped hoping for a high-quality language on the JVM.
I definitely agree about Kotlin. I think the most appealing part is the when keyword, which is almost what you would expect from pattern matching, except it isn’t.
What other languages have you tried on the JVM? I’m curious about you experience with Clojure, if any.
That and Rust’s core team are deliberately trying to avoid the biggest problems this blog post mentioned:
Rust will never have a breaking migration like Dotty or Python 3 (or, $DIETY forbid, Perl 6). Rather than fixing soundness holes by releasing an entirely new language, Rust just ships both verification passes and issues warnings if their results differ, until eventually the red line is drawn and NLL is permanently shipped. And rather than fixing papercuts by releasing a whole new language, they just use “edition numbers,” basically the same thing as use strict.
Also, the thing where Scala is supposed to “hand over the improvement process to the industry” is exactly what Mozilla already did. I only counted two Mozilla employees on the core team, with a lot of others employed by random companies like NPM, CloudFlare, Pingcap, Integers32 (which, being a Rust consultancy, really isn’t “random”). Other teams have members from Microsoft, Parity, Chef, Ferros systems (the other Rust consultancy), Diffeo, Wayfair, RMS… While Mozilla seems to have more employees than anyone else still, I’m pretty sure they’re less than half (it’s hard to be sure, because some team members don’t list their employer at all, so it’s hard to tell if they’re unemployed, academically employed, or employees of a company that didn’t fill it in on their GitHub profile).
Thanks for the writeup! I haven’t counted recently, but already at RustFest Kyiv 2017, the quoted number of contribution Mozilla vs. non-Mozilla was <25% Mozilla. I’m sure that stayed the same.
BTW, there’s also members of Ferrous Systems in core (me), but not by virtue of being employed at Ferrous. Core team is picked by involvement in parts of the project and willingness to do meta things (like legal, phew), Carol from integer is also one of the core maintainers of crates.io, Ashley is very active in the WASM side, Steve is docs team, etc.
This… doesn’t read as optimistic as the subtitle initially makes it sound. I hadn’t known about Scala 3/Dotty, but making all users execute a migration to stay on the supported path sounds like a very great way to make those users contemplate a rewrite.
If you disregard the rather melodramatic envelope this article contains more fantasy than fact. Scala 3 is binary compatible with 2.13, the Scala 3 can compile 2.x code, the compiler can automatically rewrite 2 code to 3.
I get the feeling fommil is angry that people stopped caring about ENSIME and went over to bloop/metals. I laud him for his contribution to ENSIME but at the same time he was one of those difficult /r/hascalator people who write melodramatic “bye Scala” posts and sneer from the sidelines pointing out Haskell is better. Compare this to @soc who had something interesting to say when he stopped working on Scala.
That Scala 3 is a smaller language is a complete lie, and people who keep repeating it without checking should stop it.
(Even a rough back-of-the-envelope calculation of things added vs. things removed paints a clear picture.)
I think the number of people who left Scala on bad terms should give you a pause whether “it’s those people’s fault” is a plausible scenario.
It’s a classic situation of “if everywhere you go smells like shit, maybe it’s time to check your own shoes” for Scala devs.
Do you have a better list of things added vs things removed? I’ve just considered the size of the grammar, but didn’t look at the feature level, which I see can be misleading. It’s true grammar size isn’t always authoritative when it comes language complexity.
I can only think of two people within the past few years who have made a public exit announcement . fommil and you. Most probably make quiet exits, those are the ones to worry about.
The hardware description language Chisel uses Scala to capture electronic circuit designs, kind of like Verilog and VHDL. It seems to have gotten a fair amount of academic adoption but it also has received some industry push back. Chisel’s success also seems to be in spite of Scala, not because of it. From what I can tell Chisel has spread largely because of RISC-V growth. Some popular RISC-V cores are implemented in Chisel.
The couple of times I’ve written Scala for any sizable chunk of code, I came away underwhelmed. When I was in college, it was interesting because I knew OOP and wanted to learn FP. After using it for actual work, I’ve decided I’d instead write Java or Clojure.
That’s an interesting statement. My impression was that Scala Native is explicitly not a “performance booster” for your existing big webapp, but a different “profile” of the language oriented entirely towards lower level, closer-to-metal programming. The one thing I remember about it is stackalloc variables.
Why should it? It’s another boil-the-ocean solution at the language-level, for people who are obsessed with syntax.
Language designers should aim for less, not more. Go and Clojure embody this: find/build features in libraries, quit looking for party tricks. Lua 5.1 is wonderful because it’s finished. Urbit versions its language by decrementing towards zero, where change will stop.
Scala is one of the languages that make me wish that there’d be some sort of process to sunset a technology. That we could come to a decision that it’s done now and we can collectively stop using it altogether.
Interesting article, although I disagree with the sub-title “And it Still Could”: Scala is in an irreversible decline.
None of the problems Scala faces are new; if there was willingness to fix them, they would have been fixed years ago.
Instead, the language has been bleeding out for a long time already; both in quantity (since Kotlin was released), and quality (good luck getting competent external contributors with Scala’s reputation of treating people).
Here is my take on it from a few years ago: Six Years of Scala Development: Departure.
And if you get past that, the Scala compiler’s code is considered a massive mess by most people who have worked on it. Things that seem functional but are actually backed by weird mutation at distance. I had hope that Dotty would be better, but it somehow followed the exact same patterns the original did!
Why would you expect that things would be different, given that it’s led by the same person?
People do learn from their mistakes! Occasionally ;)
I did quite a lot of Scala work at GettyImages and introduced it in a Java team for a telecom company, plus I maintain an open source project (bigsense.io) written in Scala as well.
There is still industry use, my city has a Scala meetup and there are companies here that use Scala … that being said; I’m currently working in a Clojure shop (doing devops, so I don’t really touch/can’t compare Clojure).
Yet .. all the points this article brings up are totally true. I hate the abuse over operator overloading and implicites to make DSLs. Seriously, just keep it all consistent Scala instead of making your own language. I don’t want to learn your weird operators. Half of the Scala libraries just seems like they’re duck tape for converting between types. The core language is alright, but a ton of libraries out there can get insanely complex.
Also, SBT can go die in a fire. The crazy macro expansion and other limitations make it difficult to do a lot of common multi-stage build steps. Opening up the source code will make you want to stab yourself in the eye with an ice pick. On newer projects I tend to just use gradle with Scala .. which has its own interesting problems (most around tutorials exclusively having instructions for SBT that don’t work with any other build tool).
I’ve always wondered why Scala has introduced SBT instead of using regular Gradle? It seems it does exactly the same kind of job that Gradle is designed to do, where Gradle is used by more people and is older?
There are some Scala specific things you can do with SBT which I’m not sure if you can implement in Gradle.
sbt consolebuilds you a REPL against your current code base and all dependencies so you can try thing out live.sbt ~consoleis the same with hot code rebuilds.Although after doing a search, it looks like someone found a solution:
https://stackoverflow.com/questions/35632085/scala-repl-in-gradle
Is there any source to support such claim? I briefly looked at Dotty’s website but apart from a few dropped features didn’t find anything that alarming.
Blog written by Odersky claims that:
Heck, further down he even claimed that it’d be possible to use Scala 2 artifacts, use
-language:Scala2option that “lets it compile most Scala 2 code and at the same time highlights necessary rewritings as migration warnings” or even that “compiler can perform many of the rewritings automatically using a -rewrite option”.My judging is that the tone of the article was unnecesarily dramatic and unless some crucial information is hidden from project’s website and Odersky’s blogpost, I really do understand why Scala dev’s would perceive it as toxic trolling or FUD. It’s generally good to avoid overly emotional people who fail to disclose sources for their statements.
I think the author is spot-on with his article.
Scala devs have mastered the ability to promise things and then do a switcheroo and reinterpret what they said in the most restrictive way until they can claim they “never said that”. Also, claiming that things one doesn’t like hearing are “toxic” or “FUD” is Scala community management 101.
Like when they tried to make it appear as if Scala 3 was a smaller, simpler language, when it’s painfully obvious that it’s not true. I’m just waiting for them to claim “that this was only talking about our (useless) DOT calculus, people must have misunderstood us!”.
Speaking from my personal experience, Martin saying $thing does not convey whether they are in fact true or not, only that saying $thing was most convenient at that point in time.
All I ask for is some evidence. I could easily go and make ill-minded fake accusations about virtually any project and, provided the community is large enough, there would probably be a handful of people agreeing with me. I’m definitely not saying that’s the case here, but at the same time would much rather construct my own opinion instead of just adopting one.
It all boils down to providing some verifiable statements – most preferrably with sources. After making sure these statements are correct (or at least probably correct, depending on how much I care), I can make my own judgement.
Since I didn’t get a single example of “a dramatic change” that would require “all Scala developers to be retrained and all codebase to undergo a migration”, I tried to search them up myself. What I found seems incompatible with Scala 2, but not really “dramatic” and recquiring a complete retraining.
Now you are saying that Martin Odersky is not trustworthy – again without a single example that I could look up and verify. Since Odersky isn’t the one starting the emotional battle here and I value him for his previous work, I trust him more.
So far the only thing I learned is that some people have negative feelings about Scala and its community. To convince me to join them, it’d take a whole lot more than that.
PS: I learned a little bit of Scala a while back and always thought it was an interesting and in a way a really nice language, but at the same time was somewhat sceptical about using it for larger projects. I generally tend to think that overly complex languages are a source of pain in a team work.
I have a hard time in figuring out what the problem is? Obviously, it’s not unusual to say different things on different occasions, in several levels of detail. Or things may have been true in the past, but are not now. Are you saying that Martin actively says wrong things?
I once tried to talk to him about wanting to work on improving the Scala websites’ documentation for beginners. His response was that it wasn’t necessary because “everyone already knows Scala”.
After multiple other efforts and offers to help I announced that would give up trying to improve the website if nobody cared.
That’s when he suddenly claimed that he was happy to receive contributions.
This caused me to leave Scala, because I’m not willing to be gas lighted in front of a thousand people, and it’s frankly not my problem that he says different things in private and public.
Then there was the time where he sent an emotional email to my university’s dean about some non-existing thesis, others have spilled some of the beans here.
Thanks! That clears things up a little for the bystander.
I heard about the website thing being a regular issue.
It’s interesting to see compile-time framed as if it were a tooling issue. Language design affects it deeply. Go will be fast no matter what. Languages like Scala and C++ have some features that are inherently costly. At that point, the real gains come from providing guidance about what features/dependency structures to avoid.
A possible counter-example here is D, which has the same momomorphization compilation model as C++, but is prized for the fast compiler.
Is there anything reasonably in-depth written on why it’s faster? It seems implausible that it’s entirely due to just being a really good compiler and 100% unrelated to the design of D as a language. Two heuristic reasons to guess that there must be some relationship: 1) the primary D designer was also the primary compiler implementer with a long history of compiler implementation, so seems likely to have been at least somewhat influenced in his design of D by implementation concerns, and 2) nobody has written a fast C++ compiler, despite there being a big market there (certainly bigger than the market for a fast D compiler). I could be wrong though!
I unfortunately don’t know of such an article. The folklore explanation I think is that dmd backend is much faster than llvm/gcc.
I’d like to see more detail about the claims that the scala dev team are weaponizing the Code of Conduct to suppress criticism of technical decisions and the no-platforming of a prominent contributor.
I found the first sections of the article quite reasonable, but in the end when the author suggested one visit a subreddit other than the official one left me with a feeling he has an axe to grind.
The “official” subreddit is dead after they banned pretty much everyone not falling in line with the official opinion on everything.
Imagine e. g. r/rust where almost every submission has between 0 and 2 replies.
That’s Scala community “management” for you.
The Scala community has had lots of ugly little spats. People have been banned from the /r/scala reddit, from the {users,contributors}.scala-lang.org discussion forums, and even projects have been pulled from the Lightbend (formerly known as Scala) community build server which checks compiler compatibility against popular projects. This is just the most recent stuff off the top of my head. Plenty of earlier contributors have left, some with some public hard feelings, others quietly. If you’re not part of the community, be thankful and move on is all I can say. There’s no need for you to go down the rabbit hole of this petty drama.
What do you want to know, except “that’s exactly what they do”?
I dunno, perhaps some URLs? References or citations of any kind? Something more than bare assertions. Help me believe.
[Comment from banned user removed]
Read Hail_Spacecake’s post. About that.
Supporting evidence has a way of, um, supporting an opinion.
Your reaction might be appropriate if I were a supporter of the Scala party line who was sealioning you, but I am not a part of the Scala community and have not really been watching this happen very closely. I knew about Scala 3/Dotty but not all the interpersonal stuff this article mentions. I think most of the posters here are in the same boat as me. So rather than whine about having to point to some, any evidence about the assertions the article makes and you seem to support, make both of our lives easier and show me something.
Otherwise this is all hearsay, and we the uninformed readers are left choosing one side or another to place faith in. Faith is trust without evidence, and I’d like to avoid that.
I’d like to see exactly what claims were suppressed as violating the CoC and what the dev team’s stated justification for treating them as such was. I’d like to see what the person who was no-platformed said that made the dev team think no-platforming was warranted.
My immediate thought upon reading that sentence was “why isn’t this a link so that I can read the policy?”
This is it? https://www.scala-lang.org/conduct/
I find it very odd to see “Python3 and Perl6” in one sentence. Python3 has succeeded despite the mismanaged transition—but it’s also far less of a dramatic change than Perl6. Not sure about Scala 3, I haven’t looked.
Python 3 is doing quite well, but the other shoe - of actually ceasing to support python 2 - has not yet dropped. We’ll see what happens then.
Legacy systems are the norm. The new one runs in parallel instead of replacing the old one given its many users and investment. That both are doing well is probably a good thing in light of this.
Sure. Which is why python 2 ceasing to receive even security patches is going to prompt some responses.
We’re either going to see pushes to migrate (what guido and the python dev gang expect) or some efforts to continue running those python2 codebases with security patches (maybe a switch to pypy and continued community support of that project). The latter has the potential to reshape the politics of the python community.
“dev gang” sounds weird? Is that really a term that is used in the python community?
The Ruby community has found solutions to that. There’s specialised agencies keeping old codebases secure for old Rails and Ruby versions against reasonable fees. It’s infeasible for community maintainers to support legacy.
On the other hand, as rough as it was, the MRI team has also made sure that there’s feasible migration paths, so that you can make a reasonable decision whether to put money/effort into migration or paid maintenance.
I see “python-dev” used pretty frequently in the Python community to refer to the language developers (as distinct from library developers or the wider community) — it’s a reference to this mailing list.
The question is really about who’ll be providing the support. There is no question in my mind that there will be Python 2 updates following the drop dead date for support. The question is whether the Python core team will decide to push the updates, have support forked by another community, or whether vendors (ActiveState, RedHat, etc.) will be the ones driving the support. The thinking seems to be that it’ll be the latter since open source projects have much less reason to get stuck than companies. That said, I’m sure the Python core team would consider pushing an update for some critical (security) issue, if it was decided in the best interests of the community and industry. I doubt that scenario will arise though, but it’s a possibility for a well run and organized community to consider.
Where does your understanding of Guido’s expectations come from? I’ve been present at all PyCons since 2008, except two in recent years. I’ve never seen explicit expectations like the ones you describe from Guido, or others in leadership positions. They have been pretty pragmatic with their understanding of how any Python 2 to 3 migration will happen with an understanding that eventually it’ll make sense to sunset Python 2. The wider Python and online communities however have understood or listened to little of what has been said. That extends to async, and many other developments in the language/runtime over the past decade.
I used Scala a bunch at Apple, and then my current teams use it. I really find it grating, for the same reason I find C++ grating – it is just a giant pile of stuff without a clear through-line, and it encourages all kinds of nasty shorthand. It is almost perfectly designed to irritate me, but since I’m just a Mr Manager Person now, and no longer expected to generate it, I can accede to my team’s desire to use it.
But I’d never recommend that anyone start a new project with it.
I counter that as a manager, you have more of a responsibility to identify and defuse team-draining issues than the individual contributors do.
This is true, yes. I am comfortable with the team’s usage of Scala (lots and lots of Spark), and the team is comfortable with the insanity. I just stay the F. away.
Ah, Spark is one of those nagging reasons to use Scala that’s hard to avoid when you need it. You have my sympathies. Please try to maintain space for the non-Haskell developers on your team, or you may find them running for the exits before too long. Speaking from experience.
Yeah, it’s sort of the lingua franca. Happily, my people are more into Spark than they are into Scala, so I’m not that worried that some of the horror will creep in.
Noting that PySpark lags Scala in the Spark API in some areas, is Python a viable option where Scala is troublesome in your case?
To address some of the author’s complaints — when judging from the lens of other languages and ecosystems — and note that I refer to Haskell, because it is the author’s current favorite programing language …
Compilation times are a problem, especially for libraries where macros are involved
Tooling for Scala is in my opinion, great and I have much experience with many other ecosystems, including Java, Node.js/JavaScript, Python, Ruby, Perl, .NET and Haskell
ghciandghcid(which is basicallysbt consoleandsbt ~compilerespectively), everything else suckssbtwhenever I’m building projects for anything non-ScalaIt is indeed hard to hire Scala developers, but have you ever tried hiring Java developers that have some knowledge of multi-threading and asynchrony concerns?
Hiring good developers is not easy at all. Also one mistake that people make is to hire Java developers and then retrain them for Scala. I think this is a mistake …
Hire Node.js / TypeScript developers instead. JavaScript developers tend to be familiar with the style of functional programming practiced in Scala — too bad they write quite shitty code due to their dynamic typing roots — but you can filter those out by selecting for TypeScript experience. I now believe that Node.js + TypeScript devs are better candidates. And that’s not the only pool you can search in.
The real problem are the concepts involved, which aren’t at all easy to grok:
nullmapandflatMapeverywhereThe more you go down this path, the WTFs per minute increase exponentially. As you read this list, you should realize this isn’t about the language at all, but about its functional programming culture. It’s in fact much harder to hire for languages like Haskell. The more you diverge from the mainstream practices, the harder it is to hire. That’s why Go, like PHP before it, is a raging success
Java hasn’t caught up in any meaningful sense.
And that’s in fact a problem, because the pool of Java developers familiar with basic FP concepts is very small, which is one reason for why we’ve got an inability to hire people. I’m now more inclined to hire from pools where devs are familiar with basic FP concepts.
I want Java to catch up, just a little would go a long way. It doesn’t and anybody that watched Java’s evolution should know that the language has been historically super conservative, all meaningful improvements going into the runtime and I don’t see that changing. Many people have been screaming for C#’s features since 2001 at least.
Scala 3 is going to be a great release. The reasons why I like Scala 3:
Option, but this is a tagged type; having the ability to express nulls via the type system is great, because it reduces the accidentsThis is a list of features that simplify the language and if there’s breakage involved, then it’s worth it.
Also Scala 2.14 binaries are going to be binary compatible with Scala 3. This is not the same situation as with Python 3.
In your career it’s important to not get bitter — tools are tools. If a tool stops working for you and you can’t invest in that ecosystem anymore, then simply move on.
And criticism should be welcome, but make it constructive. This article contains criticism that’s not constructive. Nonconstructive criticism isn’t criticism you make in the hope of changing things and it leads to anger and resentment, both for you and your readers.
Curious. I’ve really enjoyed working with Scala and I consider it a really nice language. I would love to do 100% of my work in Scala again (prior project/company was heavy Scala). I do agree shapeless is weird.
I also wonder about shops who hire exclusively for specific tooling on top of a language (Play, Akka, etc). That seems spectacularly dumb, and no shop I’ve worked at has even floated that as a thing to possible hire for - and I’ve been involved in hiring discussions for the last decade or so. Is that a thing outside of consultancy hiring?
Rust gets similar complaints about compile times and complexity, but its adoption seems to be on the S-curve:
https://www.openhub.net/languages/compare?language_name[]=rust&language_name[]=scala&measure=contributors
Rust has some unique selling points, Scala doesn’t.
This has been my general feeling with Scala. I have worked through some Scala books 2008-2012 and wrote some Scala programs for internal use. I also encountered quite a lot of student-submitted Scala code in one of my courses a few years back, because a colleague had taught a Scala seminar. To me Scala resembled C++: a lot of accidental complexity, trying to be everything to everybody, and long build times without the main benefit of C++, namely performance. I think the only minor benefit was that gives access to JVM ecosystem (if you need that), but for the people who just wanted a better Java there is Kotlin and Java >= 8 now.
True.
The only sad thing is that – when only looking at the common language subset shared between Kotlin and Scala – Scala is substantially better than Kotlin.
I’m back to Java, and simply stopped hoping for a high-quality language on the JVM.
I definitely agree about Kotlin. I think the most appealing part is the
whenkeyword, which is almost what you would expect from pattern matching, except it isn’t.What other languages have you tried on the JVM? I’m curious about you experience with Clojure, if any.
Scala can’t match Rust’s speed, though.
That and Rust’s core team are deliberately trying to avoid the biggest problems this blog post mentioned:
Rust will never have a breaking migration like Dotty or Python 3 (or, $DIETY forbid, Perl 6). Rather than fixing soundness holes by releasing an entirely new language, Rust just ships both verification passes and issues warnings if their results differ, until eventually the red line is drawn and NLL is permanently shipped. And rather than fixing papercuts by releasing a whole new language, they just use “edition numbers,” basically the same thing as
use strict.Also, the thing where Scala is supposed to “hand over the improvement process to the industry” is exactly what Mozilla already did. I only counted two Mozilla employees on the core team, with a lot of others employed by random companies like NPM, CloudFlare, Pingcap, Integers32 (which, being a Rust consultancy, really isn’t “random”). Other teams have members from Microsoft, Parity, Chef, Ferros systems (the other Rust consultancy), Diffeo, Wayfair, RMS… While Mozilla seems to have more employees than anyone else still, I’m pretty sure they’re less than half (it’s hard to be sure, because some team members don’t list their employer at all, so it’s hard to tell if they’re unemployed, academically employed, or employees of a company that didn’t fill it in on their GitHub profile).
Thanks for the writeup! I haven’t counted recently, but already at RustFest Kyiv 2017, the quoted number of contribution Mozilla vs. non-Mozilla was <25% Mozilla. I’m sure that stayed the same.
BTW, there’s also members of Ferrous Systems in core (me), but not by virtue of being employed at Ferrous. Core team is picked by involvement in parts of the project and willingness to do meta things (like legal, phew), Carol from integer is also one of the core maintainers of crates.io, Ashley is very active in the WASM side, Steve is docs team, etc.
That graph is irrelevant, it appears to be tracking changes to the language itself
[Comment removed by author]
This… doesn’t read as optimistic as the subtitle initially makes it sound. I hadn’t known about Scala 3/Dotty, but making all users execute a migration to stay on the supported path sounds like a very great way to make those users contemplate a rewrite.
If you disregard the rather melodramatic envelope this article contains more fantasy than fact. Scala 3 is binary compatible with 2.13, the Scala 3 can compile 2.x code, the compiler can automatically rewrite 2 code to 3.
Compared to Scala 2, the Scala 3 grammar is smaller and features are getting removed, not added.
I get the feeling fommil is angry that people stopped caring about ENSIME and went over to bloop/metals. I laud him for his contribution to ENSIME but at the same time he was one of those difficult /r/hascalator people who write melodramatic “bye Scala” posts and sneer from the sidelines pointing out Haskell is better. Compare this to @soc who had something interesting to say when he stopped working on Scala.
That Scala 3 is a smaller language is a complete lie, and people who keep repeating it without checking should stop it. (Even a rough back-of-the-envelope calculation of things added vs. things removed paints a clear picture.)
I think the number of people who left Scala on bad terms should give you a pause whether “it’s those people’s fault” is a plausible scenario.
It’s a classic situation of “if everywhere you go smells like shit, maybe it’s time to check your own shoes” for Scala devs.
Do you have a better list of things added vs things removed? I’ve just considered the size of the grammar, but didn’t look at the feature level, which I see can be misleading. It’s true grammar size isn’t always authoritative when it comes language complexity.
I can only think of two people within the past few years who have made a public exit announcement . fommil and you. Most probably make quiet exits, those are the ones to worry about.
The hardware description language Chisel uses Scala to capture electronic circuit designs, kind of like Verilog and VHDL. It seems to have gotten a fair amount of academic adoption but it also has received some industry push back. Chisel’s success also seems to be in spite of Scala, not because of it. From what I can tell Chisel has spread largely because of RISC-V growth. Some popular RISC-V cores are implemented in Chisel.
The couple of times I’ve written Scala for any sizable chunk of code, I came away underwhelmed. When I was in college, it was interesting because I knew OOP and wanted to learn FP. After using it for actual work, I’ve decided I’d instead write Java or Clojure.
That’s an interesting statement. My impression was that Scala Native is explicitly not a “performance booster” for your existing big webapp, but a different “profile” of the language oriented entirely towards lower level, closer-to-metal programming. The one thing I remember about it is
stackallocvariables.Why should it? It’s another boil-the-ocean solution at the language-level, for people who are obsessed with syntax.
Language designers should aim for less, not more. Go and Clojure embody this: find/build features in libraries, quit looking for party tricks. Lua 5.1 is wonderful because it’s finished. Urbit versions its language by decrementing towards zero, where change will stop.
Libraries, not languages.
Sounds unpleasant. I guess “Scabs” was taken.
I always describe it as a compiler experiment that escaped the lab, like the rage virus from 28 Days Later.
Scala is one of the languages that make me wish that there’d be some sort of process to sunset a technology. That we could come to a decision that it’s done now and we can collectively stop using it altogether.
The end of this article includes DRAMA. lol
[Comment removed by author]