First Yammer, then LinkedIn, then Twitter, and now movio.co. The exodus away from Scala continues.
Twitter has not moved away from Scala.
Making the move from Scala to Go
21–30 of 378 posts
Re: Making the move from Scala to Go
#22Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.
How much code do you have that compilation is 3 minutes?
Re: Making the move from Scala to Go
#23Looking through the really abstract scala code they linked brings up a problem that really frustrates me in haskell. Why doesn't anybody document their really abstract code? You know it's going to be confusing, so why not help out? If I have a type like
def foreignKey[P, PU, TT f . g x . (h (i x) $ j y z) . k $ aNamedVariable
let descriptivelyNamedFunction = (h (i x) $ j y z)
anotherDescriptivelyNamedVariable = descriptivelyNamedFunction . k $ aNamedVariable
in f . g x $ anotherDescriptivelyNamedVariable
edited for clarity, i hope
Re: Making the move from Scala to Go
#24As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "…
Agreed, but they also complained about map() and flatMap(). I have to think that eventually every developer can understand the more straightforward monads, functors, and Either - which, along with type aliases, IMO, can make code a lot more readable. I think the more esoteric features should be reserved for complex code, especially if it's possible that those features can prove runtime correctness at compile time and…
The full comment is actually:
> No map, no flatMap, no fold, no generics, no inheritance… Do we miss them? Perhaps we did, for about two weeks.
So they weren't complaining about map and flatMap, they just missed them.
Re: Making the move from Scala to Go
#25First Yammer, then LinkedIn, then Twitter, and now movio.co. The exodus away from Scala continues.
Regarding LinkedIn, they are not moving away from Scala AFAIK. And Yammer was a long time ago. Note that Scala has improved quite a bit since then, especially with the release of 2.12.0 (Java 8 support). I don't understand why, but there seems to be a lot of negativity aimed towards Scala. It's a solid language backed by the JVM, has great Java interop, and beautifully combines OOP and FP in a way I've never seen in…
Using another language that has tooling problems & slow compile speeds, I can understand why that alone would make you not want to use it anymore.
After a certain point all of the advantages of the ecosystem starts going away if compile/indexing speeds are not good and tooling doesn't work.
Golang was designed from the start to make tooling and fast compile speeds a first class citizen from the start. It has a lot of decisions that make sense when your working with large teams.
Re: Making the move from Scala to Go
#26 It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala
Re: Making the move from Scala to Go
#27Looking through the really abstract scala code they linked brings up a problem that really frustrates me in haskell. Why doesn't anybody document their really abstract code? You know it's going to be confusing, so why not help out? If I have a type like def foreignKey[P, PU, TT It's not sufficient to document the function's arguments. You also need to document the type variables! Likewise in haskell with code like f…
What do you mean "document the types". They're type parameters... can you suggest better names for the parameters in StrongSyntax?
Re: Making the move from Scala to Go
#28Making the move from Go to X, and why we're not going back (2018)
Re: Making the move from Scala to Go
#29Worked with a principle engineer once who used language as a litmus test. If you could not understand functional programming like Lisp or MLs, he'd just know not to get you on his team.
Obviously, most of the software could be written by monkeys, and only need to produce trivial functionality, in those cases, please switch to Go or at least stick to Java or C#. I say that because in the hands of someone who doesn't know, more expressive languages can cause havoc, and turn really messy. Especially the hybrid languages like Scala.
Re: Making the move from Scala to Go
#30Earlier quoted context omitted.
Regarding LinkedIn, they are not moving away from Scala AFAIK. And Yammer was a long time ago. Note that Scala has improved quite a bit since then, especially with the release of 2.12.0 (Java 8 support). I don't understand why, but there seems to be a lot of negativity aimed towards Scala. It's a solid language backed by the JVM, has great Java interop, and beautifully combines OOP and FP in a way I've never seen in…
Using another language that has tooling problems & slow compile speeds, I can understand why that alone would make you not want to use it anymore. After a certain point all of the advantages of the ecosystem starts going away if compile/indexing speeds are not good and tooling doesn't work. Golang was designed from the start to make tooling and fast compile speeds a first class citizen from the start. It has a lot of…
Compile times are a problem, yes, but tooling is not an issue. sbt is a solid build tool in my opinion.
Regarding the compiler, the Scala team has that as their number 1 priority right now. There is major work being done on building the compiler from the ground up [1]. Also, there is scala-native, which aims to provide AOT compilation for Scala code [2].
Scala vs. Go is an interesting comparison, but I think that they are each targeting different applications. There definitely is some overlap though. Go tooling is pretty good, but I don't see the hype. Maybe it becomes more clear if you're working on a large Go codebase? I don't know.