Making the move from Scala to Go • Hacker News Board

Re: Making the move from Scala to Go

#81

Post by deepGem » Wed, Jan 25, 2017, 4:47 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.

I think for tasks such as JSON parsing, map and flatmap like functions are really helpful. You write less code and the code is way easier to understand (for those who are familiar with map functions).

That being said, map and flatmap force immutability in some way. So you pay a price for this, either in speed or in memory, even with tail recursion.

Re: Making the move from Scala to Go

#82

Post by Daishiman » Wed, Jan 25, 2017, 4:48 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…

All good points. Java 8 has captured a lot of things that people were missing, and new languages have sprung up that have tried to strike a good balance between terseness and complexity, with Kotlin currently being the new hotness in the JVM. Scala was in the right place at the right time, but its features lack orthoginality and coherency.

Re: Making the move from Scala to Go

#83

Post by jghn » Wed, Jan 25, 2017, 4:48 AM UTC

Daishiman wrote: post #75

jghn wrote: post #51

Earlier quoted context omitted.

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

Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!"

On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agree on a lot of them, fwiw

When the metric used is "easier to read" it becomes far too subjective IMO, things you mentioned are similar but not quite the same

Re: Making the move from Scala to Go

#84

Post by jghn » Wed, Jan 25, 2017, 4:50 AM UTC

edblarney wrote: post #71

jghn wrote: post #51

Earlier quoted context omitted.

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.

And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.

Re: Making the move from Scala to Go

#85

Post by [deleted] » Wed, Jan 25, 2017, 4:52 AM UTC

nrjdhsbsid wrote: post #15

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

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…

[deleted]

Re: Making the move from Scala to Go

#86

Post by true_religion » Wed, Jan 25, 2017, 4:52 AM UTC

hliyan wrote: post #20

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

As the saying goes: it's easier to write code than understand it. Therefore if you write code as cleverly as you can, then by definition you're not smart enough to understand it...

I sometimes optimistically believe that my cleverness will increase over time.

Re: Making the move from Scala to Go

#87

Post by true_religion » Wed, Jan 25, 2017, 4:55 AM UTC

nrjdhsbsid wrote: post #15

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

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…

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

True, but once get into the length of variable names in iOS and Android development, you're in a whole new territory. 38 character variables have no place in life.

And extreme's like:

outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch

This is 149 character.

Re: Making the move from Scala to Go

#88

Post by solidsnack9000 » Wed, Jan 25, 2017, 4:57 AM UTC

mahyarm wrote: post #25

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…

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…

What does it mean to make tooling a first class citizen?

Re: Making the move from Scala to Go

#89

Post by true_religion » Wed, Jan 25, 2017, 4:57 AM UTC

jghn wrote: post #83

Daishiman wrote: post #75

Earlier quoted context omitted.

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

Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!" On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agr…

It's a judgment call where small functiosn are more readable than cohesive code.

If the 'idea' of the code isn't easily broken down into abstractions, even mentally speaking, then small functions will just obscure what's actually going on by pointing out all the implementation details that are wound together.

Re: Making the move from Scala to Go

#90

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

jghn wrote: post #83

Daishiman wrote: post #75

Earlier quoted context omitted.

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

Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!" On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agr…

In my experience, very experienced programmers end up converging towards very similar idioms: terse expressions for common patterns, clarity when the domain is complex through verboseness if necessary, and just keeping things as simple as possible unless there's evidence that complexity will reduce technical debt in the future.

I don't really see highly competent devs doing the whole J2EE architecture astronautics anymore, nor using single-char variable names. There's a tendency to write things concisely when simple, and then moving the complexity away to some other place, stashed in its own function, when it reaches a certain mental threshold of complexity. There's a tendency to use the best features languages have to offer, maximizing simplicity through orthogonal features and repeated idioms, while discarding unnecessary cruft; one of the marks of junior devs is their desire to try to fit problems into new idioms just to test out language features or strange design patterns.

Given that human intelligence is fluid but the variance just isn't that high (after all, we all have a similar amount of working memory), common design practices emerge out of this understanding for our limits for reasoning about problems. Exceptions abound in extremely technical and complicated problems (just check out non-trivial linear algebra code or bit-flipping, low-level device drivers), but the most part it just sticks out how things are made to look simple within a finite range of tradeoffs. This has been my experience in my domain of expertise; look at most current web development frameworks and they respect common patterns even in radically different languages that are really about the essence of the request-response cycle, not made-up constructs of additional complexity or a restating of the problem.