Some experience to share: I studied Scala and FP on the side before jumping to a team that was using it in production. Most of the engineers on the team have an enthusiasm to learn about and use fp.
Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others.
We program as simply as possible but when a new technique is discovered we go ahead and use it after it's been presented to the team and everyone is comfortable with it.
all code is reviewed and unreadable code does not pass
Compile times haven't been an issue. As an example a 100k line Scala program with around 900 files takes around 2 minutes to rebuild whilst incremental changes are immeasurably fast. Reloading code while a local server is running is easy by default in IntelliJ.
Using worksheets for playing is often useful.
we don't use actors where streams would make more sense and vice versa, know the purpose of your tools
I've had bad experiences with Go. I know that for the application I'm working on it would not scale to 10 programmers working and constant refactoring due to business goals changing.
I haven't tried Go myself and I've been meaning to, but I have spent the last 3 years writing Scala code. Before learning Scala I didn't have any real experience with FP, and I think that was the real learning hurdle for me. Once I learned the FP ideas Scala became my preferred language. I think it's really funny but Java and C# have been becoming more Scala like, and to some extent the latest version of JavaScript are also starting to become Scala like. What I have come to accept is that Scala does take people time to learn, but it's not typically Scala the language, it's the FP aspects of it that are the stumbling blocks.
PS. I also work on a 100k Scala program and can go from clean to compiled in less than 2 minutes, and incremental compiles are extremely fast.
If you don't have code reviews, and don't have any sort of regular teaching sessions that push people towards similar conventions, then I can see how code can become unreadable. But we really haven't had that issue w/Scala at all.
> Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others.
I think this is precisely why a former eng director at Twitter is quoted as saying he'd do Twitter in Java if he started over again. You have to spend a lot of time studying Scala. This is a no-go for any big org that wants to be efficient at horizontally scaling up engineers.
It works great for small teams or orgs that don't need to hire engineers like crazy.
Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others.
We program as simply as possible but when a new technique is discovered we go ahead and use it after it's been presented to the team and everyone is comfortable with it.
all code is reviewed and unreadable code does not pass
Compile times haven't been an issue. As an example a 100k line Scala program with around 900 files takes around 2 minutes to rebuild whilst incremental changes are immeasurably fast. Reloading code while a local server is running is easy by default in IntelliJ.
Using worksheets for playing is often useful.
we don't use actors where streams would make more sense and vice versa, know the purpose of your tools
I've had bad experiences with Go. I know that for the application I'm working on it would not scale to 10 programmers working and constant refactoring due to business goals changing.