Scala is just an amazing language. I'm very happy that the worst of the 'Scala as a worse Haskell' days is over and that the Scala community is finding it's own programming style.
I remember years ago when I had a heated discussion about local mutable state. An that time it felt like heresy to even suggest it. I just recently had another discussion with the same programmer and he was like: "Yeah, that works".
Unfortunately, "Scala as a worse Haskell" is alive and well. The /r/Scala subreddit, for example, is dominated by folks who tell every Scala-curious beginner who drops by that the accepted right way to write Scala is the pure FP ecosystem and everything else died a long time ago.
There are beautiful, simple, elegant ways to write Scala, but I'm afraid that the community isn't converging on a single concrete style, and a consensus around an abstract set of ideas about style isn't useful. Everybody agrees on words like "simple" and "elegant" and "readable," but I've seen some real abominations in Scala that people are tragically proud of. I'm afraid that Scala has attracted too many of the wrong kind of programmer, the kind that identifies their professional value with their ability to implement complex solutions that are intractable to their peers. The problem is not that you can't write simple code in Scala, but that people choose not to.
I don't want to blame the pure FP style of Scala itself, because I've seen the same problems in the "better Java" style as well, and because I'm still thinking that I might be able to write good code in this style and might even come to prefer it. But oh man, the Scala programmers I've personally worked with who embrace pure FP have really screwed up priorities.
Yep this is a huge cultural problem with the Scala community. On paper and in marketing material, Scala is flexible enough to empower you to slip into mutable/OOP style or more FP style. But in practice the pure FP enthusiasts are the ones who totally dominate the ecosystem (aside from Haoyi Li). You simply cannot just ignore the Haskell Larpers/Wannabe's and get on with it, because they infect all the community watering holes like Reddit, Gitter and Discourse. Every time one talks about using non-pure-FP features of the language, they have to go through the same tired patronizing lectures about how "yes I know this is not 'safe'" and "yes I know what I'm doing" and "I'm very sorry that I am not as smart as you smart FP people" before you can actually talk about what you want to talk about.
AFAIK a lot of the wannabe-Haskell-programmers ended up transitioning fully to actual-Haskell-programmers too, which is probably a win-win that's good for everyone involved. Life's to short to use a language you hate, different strokes for different folks and all.
I still find that Scala devs think they’re writing Haskell. From what I’ve seen in the community, no one cares about shipping code, they care about whether or not it’s “pure”.
To give them their credit. The argument from the purists is that purity is itself about shipping code. As a long-time scala developer who has started using the pure-FP ecosystem (cats,cats-effect mainly) I am starting to see their point. It takes some time to grok but once you do then it is amazingly productive to work with.
Maybe. I certainly don't have data on it but am also not sure what sort of data would actually prove that point. Teams that choose Scala may just be solving different sorts of problems. Or maybe they take longer and deliver a higher quality product. All I know if that I am personally way more productive in Scala than any other language I've used (and I have used most of them at one point or another).
> Or maybe they take longer and deliver a higher quality product.
Without going into how do you define a higher quality product, does quality really matter that much..? Most code is going to be re-written every few years anyway. Software engineers aren’t building architectural wonders that will last hundreds or maybe thousands of years. So is the complexity of a language like Scala really worth it, just to deliver a product that will be obsolete in a few years anyway?
Well, I've been working in financial and data services for many, many years now and I can tell you as much: many of the code bases I've been dealing with (and am dealing with) written in less strictly typed languages (much Python, lots and lots a lot Java) are riddled with hidden runtime errors that you'll just never see in Scala.
If there's a bug, it's usually some modelling problem or some conceptual issues, not the implementation of the code. I've much more confidence in the code I've written in Scala than the code I've written in Python or Java and I never ever had to get up and pick up the phone in the middle of the night because some production issues with code written Scala.
Java has really great tooling to make it really safe if one wants to — the problem is usually the managements’ cheapness with programmers fresh out of school/bootcamp. There are areas with high security requirements where Java is used with great success.
On the margin, yes. If a language helps to deliver a better product (fewer bugs, more dependable, etc) then your prior should be that that is a good thing that will, all else equal, make for a better product. But I don't accept the premise that it is easier and faster to deliver a working product in a different language. Maybe it is in some cases but me and my time are most productive and produce the highest quality product using Scala. And I think that has a lot to do with the language and the ecosystem itself. But ymmv and if it's not a good fit for your team then you shouldn't use it.
I would make the counter argument that I would rather have a language that _may_ be more prone to bugs and be able to easily hire engineers. Also, there’s a lot of hidden costs in over engineering something. Trying to get something to be bug free is like trying to add another 9 to five 9s of reliability, the cost is rarely justified.
Over-engineering of course is bad by definition, but my point is that is not the correct characterization. Scala is both safe AND expressive which is good for both productivity and reliability. If, of course, you take the time to learn and understand the core abstractions. To your point, yes that does take time and there is generally not a ready pool of talent you can hire with that knowledge already. So I wouldn't decide to write something in Scala if the team doesn't have any knowledge already and you're on a deadline, but you could say that about any language really. Any given team is going to deliver the fastest with the highest quality using the language and tooling they already are experienced with.
But as an individual engineer I would say that it is worth learning. Even if you don't use Scala for any major projects due to various organizational reasons, it is a great, principled introduction to a lot of the patterns that are becoming ubiquitous is most modern programming languages. One of the small pleasure in life for the moment for me is when the NodeJS devs I know who always told me static typing is unnecessary and Scala was too "academic" are suddenly gaga over Typescipt and functional programming.
Basically that, yes. The idea is, as long as the mutable state starts and ends within the confines of an individual function, you can get away with treating that function as if it were "truly" FP.
The main argument against this is that it's a concession that makes the codebase less coherent. The more hardline argument being that the encapsulated mutable state is still more prone to bugs and should be almost always be avoided, except at great cost.
There are certain algorithms that either can’t or only insanely error prone way can be expressed “purely”. There is nothing wrong with locally mutable state. It is basically the same as a State monad that is evaluated/executed — which can arguably be worse
It’s rare that you need to use vars in Scala, but still if it’s scoped to the function then you know you can mentally discount it once the function terminates.
I remember years ago when I had a heated discussion about local mutable state. An that time it felt like heresy to even suggest it. I just recently had another discussion with the same programmer and he was like: "Yeah, that works".
Good times.