4 ms·

You can find a similar comparison here: http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/ http://jimplush.com/talk/2015/12/19/moving-a-tea

by dcu 10y ago

You can find a similar comparison here: http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/ http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala...

pyrale 10y ago
I find this article much more interesting than op. In particular, the focus on keeping functional codebases simple is, I believe, the core of what makes a successful functional codebase. Basically, at some point when working languages like Haskell, Scala or F#, you are given a choice between power and ease-of-hire/onboarding. Apparently, they made the second choice, which I believe is the good one in their situation. I believe it is possible to stick to functional languages and make a team-enforced decision to keep things simple, but the choice of simply opting out of it is also on the table, and I won't blame them for it. I would just have preferred having a simple language AND a great type system.
agentgt 10y ago
Basically replace "Go" in that article with "Java 8". Java 8 makes for a much stronger argument for their situation considering they wouldn't have needed to rewrite any of the Scala code. The author of the article almost admits it multiple times. With really only one point: One of the other benefits of Go was widening the pool of backgrounds we can hire. We can take someone from any language background and have them ramped up on Go in weeks. With the Scala side there’s the JVM learning curve, the Java world of containers, black magic of JVM tuning, profiling tools, etc… Do new developers really need to know about the JVM and tuning? Hell I'm not even an expert with JVM tuning. You can go pretty far with the defaults.... Containers... nobody uses containers anymore. Profiling, debugging, monitoring tools.. ahhh the JVM has the best. You need to profile code regardless of language. That is like saying Go lang developers really need to know about C and calling channels black magic. I don't know of a wider pool than Java.

by dcu 10y ago

You can find a similar comparison here: http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/ http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala...

pyrale 10y ago

I find this article much more interesting than op. In particular, the focus on keeping functional codebases simple is, I believe, the core of what makes a successful functional codebase. Basically, at some point when working languages like Haskell, Scala or F#, you are given a choice between power and ease-of-hire/onboarding. Apparently, they made the second choice, which I believe is the good one in their situation. I believe it is possible to stick to functional languages and make a team-enforced decision to keep things simple, but the choice of simply opting out of it is also on the table, and I won't blame them for it. I would just have preferred having a simple language AND a great type system.

agentgt 10y ago

Basically replace "Go" in that article with "Java 8". Java 8 makes for a much stronger argument for their situation considering they wouldn't have needed to rewrite any of the Scala code. The author of the article almost admits it multiple times. With really only one point: One of the other benefits of Go was widening the pool of backgrounds we can hire. We can take someone from any language background and have them ramped up on Go in weeks. With the Scala side there’s the JVM learning curve, the Java world of containers, black magic of JVM tuning, profiling tools, etc… Do new developers really need to know about the JVM and tuning? Hell I'm not even an expert with JVM tuning. You can go pretty far with the defaults.... Containers... nobody uses containers anymore. Profiling, debugging, monitoring tools.. ahhh the JVM has the best. You need to profile code regardless of language. That is like saying Go lang developers really need to know about C and calling channels black magic. I don't know of a wider pool than Java.