2 ms·

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

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.

randmeerkat 6y ago
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.
- thinkharderdev 6y ago
  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.

randmeerkat 6y ago

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.

thinkharderdev 6y ago
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.