[sixminuteabs]

We develop the majority of our code in scala at my company (in fintech).

There seems to be an experience in this thread that training in Scala is difficult. For anyone who is considering and wants another perspective - I have found that junior engineers tend to get up to speed more quickly in Scala than in other languages and that I can give them more freedom (because I know their programs won't compile if they don't line their types up and our use of the type system very immediately forces them to deal with the possibility that an operation can fail, e.g.). I can simply look at types and give them a nudge in the right direction (heyoo -fp either joke-). Yes they suffer a little in the beginning, but are usually shipping code within a few weeks then their trajectory really begins to rocket. It's very cool to watch them grow to building complex systems in a complex domain so quickly. As they grow the ease of refactoring means that it is easy to change their prior work as they gain more understanding, so for our management the penalty of allowing them to learn in the wild about something that's suboptimal is pretty low - they will come back and fix it. Of course what I'm saying above is really about FP and type systems and an implicit (heyoo -scala joke-) presence of thought about how our systems work top to bottom and how we train people. I think that is also required no matter what tools you use or what you're doing in any organization?

[CraigJPerry]

>> I can give them more freedom (because I know their programs won't compile if they don't line their types up

In what meaningful way can you give them more freedom? When i think about how i spend my time with junior folks, it tends to be on things like:

1. Do they understand enough of our problem domain that i can begin to describe a problem that needs to be solved?

2. Have they understood the problem i described? How confident am i that they're not going to implement a solution to the wrong problem?

We don't spend time on "hey, you passed the parameters in the wrong order here".

To put it another way based on my experience, what's more useful to a junior developer?

Option A: Hey, here's a test case, here's how to run it. I need you to change the behaviour of this component to do X instead.

Or

Option B: Hey, here's a component with well designed types. I need you to change the behaviour of this component to do X instead.

My experience has been that Option A - play with the component hands on, try things, run it, tweak the data supplied to it and observe the results - these encourage engagement. The developer will be excited even.

And for Option B, they'll be quite dejected, not that invested in the project. I can't even compile the stupid thing because of some cryptic compile error.

[sixminuteabs]

When I say more freedom, I primarily mean freedom to focus on the problem domain and freedom to contribute in a major way more quickly. Upon reflection, I realize that my expression about optimal solution was about optimality in modeling and understanding the problem domain vs. wrestling organizational programming pattern you're trying to learn / hold in your mind while also trying to solve the domain (which you don't have to do as much with scala's compiler)

And in terms of morale, I view almost the opposite of what you're saying. Because types and the compiler enforce correctness in the program and compatibility within our systems I can have a relatively junior person thinking more about the domain and knowing that they can get something "real" into prod much more quickly with almost no risk to the org. They can move on to bigger blocks of work more quickly. Solving real, big problems and making impact gets engineers jazzed up. Regarding compilation, I find the "this won't compile" phase is almost non-existent in practice. People quickly adapt from "this thing doesn't compile [insert sad longing for python]" to "this thing won't compile - somewhere there's a misalignment with what I said I'm going to do (via types) and what I'm actually doing, [insert silent acknowledgement that they would have shipped an error in python and not known it]."

I'm not seeing where the gap is between A and B except that in option A it appears that there is no compiler involved, which per the above, means that I have to ask them to focus more on exercising mental discipline about coding conventions (boring, low value add work) and also I can't allow them to contribute as quickly because the risk they threw an exception somewhere they shouldn't have (e.g.) is higher.

[CraigJPerry]

>> they can get something "real" into prod much more quickly with almost no risk to the org

What are the most common risks to an org (originating from its code) and how do types get you down to almost no risk?

When i think of common risks, most of them don't even originate inside the process's address space so the type checker is completely disconnected from the risks (e.g. hey - you misunderstood what we wanted here...). For the risks that do originate directly from the code, it's stuff like hey - your solution is quadratic time, sure your code compiles and your tests all pass but i'm telling you this won't work under prod data volumes.

I'm trying to steelman your argument and the best case i can come up with is an IO monad.