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