Making the move from Scala to Go • Hacker News Board

Re: Making the move from Scala to Go

#71

Post by edblarney » Wed, Jan 25, 2017, 4:29 AM UTC

jghn wrote: post #51

nrjdhsbsid wrote: post #15

Earlier quoted context omitted.

I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. Some of their code is so "clever" that I've refactored the line with 7…

One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity

I'm not sure if this is true.

Scala provides a whole new level of ability for people to write code that can be meaningless to others.

It really is quite different.

Re: Making the move from Scala to Go

#72

Post by Daishiman » Wed, Jan 25, 2017, 4:30 AM UTC

skybrian wrote: post #45

WkndTriathlete wrote: post #13

Earlier quoted context omitted.

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…

A for-each loop is only slightly longer, more familiar (just about every language has it), and more flexible - it covers map, flatMap, and reduce. So why have three or more specialized constructs when one will do? There are cases when the restrictions of map() and reduce() are necessary, most famously for a map-reduce in distributed programming, but that's not really relevant for implementing a simple function.

Map, fold, reduce and friends are statements of intent, and reading a line of transformations composed on multiple maps and such is generally much clearer than reading a series of loops in which you have to figure out intent by looking and what's going on inside each loop.

Also, error density is relatively constant per line of code according to most studies (this is a very general statement, but we can assume that most code just isn't trying to be clever). I've forgotten to add(), append() and drop items inside a loop far more than I've made mistakes inside more functional methods.

Re: Making the move from Scala to Go

#73

Post by hyperpape » Wed, Jan 25, 2017, 4:31 AM UTC

danellis wrote: post #53

skybrian wrote: post #45

Earlier quoted context omitted.

A for-each loop is only slightly longer, more familiar (just about every language has it), and more flexible - it covers map, flatMap, and reduce. So why have three or more specialized constructs when one will do? There are cases when the restrictions of map() and reduce() are necessary, most famously for a map-reduce in distributed programming, but that's not really relevant for implementing a simple function.

The problem with for-each in a lot of languages is that it's a statement, not an expression, so it only works with mutable data.

I'm definitely in camp map/filter/fold, but if you instantiate a list/accumulator, fill/operate on it inside the loop, then consume it, you're essentially writing pure code. The fact that you're doing it on top of mutable foundations doesn't matter (at that scale).

Re: Making the move from Scala to Go

#74

Post by didibus » Wed, Jan 25, 2017, 4:32 AM UTC

unoti wrote: post #55

didibus wrote: post #43

Earlier quoted context omitted.

But the best thing you can do to improve the team's chances of accomplishing business objectives is to choose its members more carefully.

I agree. But personally I'd be concerned about a team lead who thinks the make or break thing is whether a candidate engineer loves fondling their monads all day.

Ya, it's a little draconian, but in practice it was more nuanced. If you just didn't know those things, it was fine, but if you couldn't learn and eventually understand them...

Re: Making the move from Scala to Go

#75

Post by Daishiman » Wed, Jan 25, 2017, 4:33 AM UTC

jghn wrote: post #51

nrjdhsbsid wrote: post #15

Earlier quoted context omitted.

I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. Some of their code is so "clever" that I've refactored the line with 7…

One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity

This is not really as subjective as you think. Research in software engineering shows that certain structures are more prone to errors than others. We know that higher cyclomatic complexity leads to more bugs, more statements lead to more bugs, and certain usage patterns lead to more bugs.

Smart people can disagree, undoubtedly, but there's a reason why GOTO is considered to be brain cancer and pattern matching is generally considered to be great.

Re: Making the move from Scala to Go

#76

Post by Daishiman » Wed, Jan 25, 2017, 4:35 AM UTC

fbreduc wrote: post #3

stcredzero wrote: post #2

As 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. "…

this is a developer problem not a language issue, i've seen "nifty" code in go just as well..

Some languages have footguns and constructs that are error prone.

Re: Making the move from Scala to Go

#77

Post by rodrigosetti » Wed, Jan 25, 2017, 4:35 AM UTC

Nice write-up. I wonder if you guys have tried using Scala as a functional programming (_no_ vars, returns, partial functions, exceptions, mutable data structures, etc.) - or just used it like in the stateful procedural world.

Re: Making the move from Scala to Go

#78

Post by Daishiman » Wed, Jan 25, 2017, 4:38 AM UTC

ludicast wrote: post #10

Scala is the latest whipping boy(1). It's a great language with tons of warts, but it actually acknowledges the warts. Case in point, when (2)Paul Phillips went after Scala (mentioned in the article), Odersky took some of that criticism to heart for the next iteration/rewrite of the Scala compiler. In an industry where everyone doubles down, that's extremely refreshing. Scala's cognitive footprint can lead to misbeha…

Well Coffeescript was refreshing in being very terse and introducing a lot of niceties that were missing in JS. It was also trivial to introduce footguns given its whitespace rules and some pretty radical syntax rules.

New Javascript has basically taken the best that CS had and wrapped it in the necessary turd that is backwards compatibility in a hastily designed language, but the results speak for themselves and modern JS is just much more pleasurable.

Re: Making the move from Scala to Go

#79

Post by Cyph0n » Wed, Jan 25, 2017, 4:38 AM UTC

mdasen wrote: post #63

Cyph0n wrote: post #17

Earlier 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…

I don't care much for language battles, but maybe I can shed some light on this. The former VP of Platform Eng at Twitter said in 2015, "What I would have done differently four years ago is use Java and not used Scala as part of this rewrite. [...] it would take an engineer two months before they're fully productive and writing Scala code." The VP of Platform Eng at Twitter expressed regret for the choice of Scala. L…

Thank you for taking the time to type up such a detailed response. I read through it more than once.

I agree with most of your points, but I still believe that Java != Scala, at least not yet. I think Scala still has a lot to offer that differentiates it from plain Java.

Re: Making the move from Scala to Go

#80

Post by Daishiman » Wed, Jan 25, 2017, 4:41 AM UTC

joneholland wrote: post #12

Sounds more like moving away from a big jvm monolith is how they gained their speed. Our Scala based microservices build in seconds. Anyway, no idea who movio is, but cool they like go. Not sure why they needed to write Scala FUD in the process.

I think that if you have to move to microservices just to avoid atrocious compilation times that means there's something horribly wrong in the language stack. Microservices should be used to solve architecture problems, not a workaround for compiler slowness.