Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making the move from Scala to Go

movio.co

Post reply on HN
Print view View original

171–180 of 378 posts

Re: Making the move from Scala to Go

#171

Post by ivanhoe »

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…

IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do that efficiently. Instead of investing some time into getting used to the peculiarities of the language that they use, they then try to avoid them as "complicated". By lowering a bar too low, and avoiding using these patterns all together, you encourage people to never train their brains to recognize them effortlessly. And by definition of common patterns, they're, well, common, and they'll keep running into them all of the time. Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.

I'm not saying that one should go crazy with one-liners or uncommon patterns, but things like ternary operators used with reasonably short expressions in a single line of code are totally valid and should be readable to any average dev out there.

Re: Making the move from Scala to Go

#174

Post by unscaled »

nine_k wrote: post #108
faitswulff wrote: post #24

Earlier quoted context omitted.

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.

They only missed these features for 2 weeks? Good for them! Their problem domain is likely so simple and neat that it fits the Go's limited built-in types well, and does not lead to frequent copy-paste programming. If so, Scala has been an overkill.

Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider:

  users.filter(_.active).map(_.email)
to be easier to read (and not a pain in the ass to type) than:

  emails := make([]string, 0)
  for _, u := range users {
    if u.active {
      emails = append(emails, u.email)
    }
  }
  return email
The first style is more explicit about what you want to do, the second style is more explicit about how you want to do it. Go made imperative vogue again, but for me it feels like a throwback all the way to Turbo Pascal. Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM.

Re: Making the move from Scala to Go

#175

Post by lazyjones »

unoti wrote: post #52

I have a simple question. In the article they mentioned they had a concurrency issue with a timed buffer that they later neatly solved with go channels and goroutines. They said that they solved the problem in Scala by moving to the actor model, but that required importing Akka into their project and training everyone how to use Akka. My simple question is: couldn't they have achieved the heart and soul of the actor…

I found the Go solution for that issue a bit odd - channels aren't for data processing, they're synchronisation primitives. Using them the way they did in the article ruined the piece for me, since it reads like a rather uninformed decision now.

Re: Making the move from Scala to Go

#176

Post by atilaneves »

michaelchisari wrote: post #4
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 don't agree that all languages are created equal in this regard. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness." For instance, python has never had the problems that ruby or perl had.

I've seen Ruby-like Python. Just because Ruby makes it easier to do metaprogramming doesn't mean you can't do it in Python.

Re: Making the move from Scala to Go

#177

Post by majkinetor »

runT1ME wrote: post #136
nemothekid wrote: post #127

Earlier quoted context omitted.

>And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". IMO, the answer is people vastly underestimate the cognitive cost of reading code. "Code" rarely exists in a vacuum, the reader has a universe of inputs, outputs, problems, solutions, failures and goals. The cognitive cost of trying to read someone's code is something that must be paid multiple times per day and at one poi…

I'll keep repeating myself: the cognitive cost of "code" is dwarfed by the cost of understanding an application . If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time. Not everyone feels this way, the investment to learn these features may not pay off right away, and if you come from a "move fast and break things" language (python/php/js) it c…

I totally agree. Plus, it keeps job interesting.

Language is important and its expressivness. Babel 17 is must read.

Re: Making the move from Scala to Go

#178

Post by misja111 »

In my experience, the larger your codebase, the more you appreciate these features:

- a strong type system

- a pure functional language so you have referential transparity

- an IDE that helps you with refactoring

If your project is small than you can do without all of those, actually they might even slow you down.

When I read the article, I get the feeling that this particular team was working on a small codebase.

Re: Making the move from Scala to Go

#179

Post by ptx »

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.

And a goto statement is even more general, covering all kinds of looping constructs, exceptions and even the eliminating the need for functions! Why not just use those?

Re: Making the move from Scala to Go

#180

Post by majkinetor »

ivanhoe wrote: post #171
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…

IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do tha…

Great comment.

Particularly

> Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.

I stopped contributing to one Powershell repository because author thought that ps is hard and he wanted Get-Process. I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful

Particulary

> Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.

Post reply on HN