
Moving a team from Scala to Golang - alexatkeplar
http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/
======
memracom
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.

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

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

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

------
danielvf
The sample code about halfway down the article is worth seeing.

It has been said that you can write Fortran in any language. Perhaps there
needs to be a similar proverb about Haskel?

------
paulddraper
"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.

------
paulddraper
"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.

------
mark_l_watson
Useful write up.

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.

------
wkcamp
"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.

~~~
memracom
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.

------
fithisux
You took the right decision.

