First if all, I don'[t think it is a good idea to let developers get away with just including any random library they feel like. Part of your code review should be to check the build,gradle, pom.xml or Makefile to make sure that added libraries are thought through.
Some libraries are targeted on doing one job well and using them is a great idea. But other like scalaz are hugely filled with implications, not the least of which is to UNDERSTAND how to effectively use it.
I don't use scalaz at all, not because I don't believe in functional programming, but because I believe in Scala functional programming and I want to make sure that I write code that other Scala developers can understand.
I'm not saying that scalaz is bad or good. It's just that it is a big deal and the whole team needs to drink the koolaid to get a real benefit. You could say the same about Apache Camel which is a wonderful tool that more people should use, but when you see it tucked into only one class of an app with roughly 100 classes, you wonder what is the point. Akka is the same kind of thing. You either embrace something like that or you avoid it. And make sure that everyone in the team is involved in the discussion.
I wonder, did it occur to the author that problems he is talking about have nothing to do with Scala? It's about setting company standards and managing people. Assuming that adopting more restrictive and less expressive language will solve the problem of сurbing "loose canon" developers is naive at best. The only result of such transition would be loosing good developers. Talented people are very hard to tame and that's what management is supposed to be about, not about getting bigger paychecks. So the company will eventually degrade to the very average level, where competitive advantages are hard to achieve. Of course in many cases competitive advantages are unrelated to development per se, so such transition is not necessary bad. But in what way it says anything about Scala or Go and programming in general?
We use Scala in production @ Expedia. Most of the developers are from a Java background and are using it as "a better Java", and not as "a worse Haskell".
I find its best to avoid the Scalaz library and it's community.
> This was to be something the whole team could work on but half the team didn’t want anything to do with it. The developer who wrote it is a brilliant person but the fact it divided half the team was a problem.
This is basically an admission that they're using Go as their Blub language because it's all the underqualified half of their team can handle. I wish they had shown the Go equivalent of that code, because I assume it's hundreds of lines of repetitive boilerplate that takes the same effort to work through no matter how smart you are.
"SBT is also a real sore spot. There’s always that one person who actually knows what the heck SBT is doing and can debug everyone’s issues."
SBT is an order of magnitude easier to debug then Make or (heaven help you) Maven. I'm not saying it's the best or simplest build tool ever made, but it has nice debugging. `inspect` and `show` are invaluable.
"Unfortunately, at Gravity we didn’t have required code reviews in place."
If you are trying to scale past 50 devs without code reviews, there is a MUCH easier improvement you can do rather than to switching to a new language and tech stack.
Even though I really enjoyed the Scala functional programming course at Coursera, I decided to not use Scala in anger on any real projects because of the complexity. Java 8 is good enough and the code is much easier for people to read and understand.
I keep going back to Haskell even though I am not that effective with the language, but that is largely for enjoyment and because I am mostly retired now so if I spend extra time using Haskell I don't mind the productivity hit.
"Scala has a lot of rough edges already around getting a build environment, SBT pain, IDE environment pain" I never had this issue with Scala. Maybe because I'm an independent dev, but regardless, I had scala, sbt, emacs, and g8 ready within 5-10 minutes.
I don't use emacs or sbtg or g89, and I never had any problem getting set up with Scala, either at the company where we used Eclipse with maven builds or now where we use Intellij with gradle builds.
But learning how to use IDEs and build tools and even git or svn, effectively is definitely a learning curve. Just don't blame your hassles on a programming language.
Some libraries are targeted on doing one job well and using them is a great idea. But other like scalaz are hugely filled with implications, not the least of which is to UNDERSTAND how to effectively use it.
I don't use scalaz at all, not because I don't believe in functional programming, but because I believe in Scala functional programming and I want to make sure that I write code that other Scala developers can understand.
I'm not saying that scalaz is bad or good. It's just that it is a big deal and the whole team needs to drink the koolaid to get a real benefit. You could say the same about Apache Camel which is a wonderful tool that more people should use, but when you see it tucked into only one class of an app with roughly 100 classes, you wonder what is the point. Akka is the same kind of thing. You either embrace something like that or you avoid it. And make sure that everyone in the team is involved in the discussion.