Live data from Hacker News

Making the move from Scala to Go

movio.co

141–150 of 378 posts

Re: Making the move from Scala to Go

#141

Earlier quoted context omitted.

Unfortunately, ternary operators eventually end up like this due to refactoring blindness: usefulMetric = wantComplexCalc ? (complexity > 40 ? superComplexCalc(foo) : regularComplexCalc(foo)) : simpleCalc(foo);

At some point you have to rely on policy and not language constraints. I submit that no language is constrained enough to protect against refactoring stupidity while also being flexible enough to be useful to the average programmer on the average project. If not ternary if, it will be something else. So, do you throw out every alternative method to accomplish the same thing, or do you put policies in place to keep th…

In all honesty, I prefer having rules that have no special-case 'unless' issues. It's too much effort/trouble to remember all the cases where things don't work. I'm a good engineer but a terrible compiler.

I believe part of learning a new library/framework/language is to limit yourself to a certain subset of the API offered. After working with Ruby (the language) and Javascript (the ecosystem), I feel like that's the only way to preserve your sanity and productivity. I don't need to know 4 different ways of creating a lambda in Ruby, selecting 1 that can express the other 4 is good enough.

---

In this case, the rule would be no ternary operators, since they work well unless you nest them or unless you make them long/complicated.

Other examples -

You don't need to wrap if conditions unless you have a multi-line body:

  if (myCondition)
    x = 42;
    y = 23;
Early returns simplify short circuiting logic unless your function becomes too long:

  if (myVariableAtBeginningOfFunction) {
    return true;
  }
  ...
  // 2 screens later
  ...
  if (x == 42) {
    return false;  // why am I not getting false?!
  }
Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy:

  if (person.isStudent) {
    showSchool();
  }

  if (person.age) {
    showBirthCertificate(); // what if age is 0?
  }

Re: Making the move from Scala to Go

#143

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

Yes, the frustrating thing was that people previously praised the language _despite_ its obvious footguns. A language where 'dropping parentheses where you can' is idiomatic is a disaster waiting to happen.

I don't know about you, but I never want to be holding a footgun, ever.

Re: Making the move from Scala to Go

#144
post #22

Earlier quoted context omitted.

How much code do you have that compilation is 3 minutes?

Its not go code fully. Its java that takes 3 mins. Go takes very less time like 3-4 secs. Multiple smaller services so we compile only what we change.

> Multiple smaller services so we compile only what we change.

Also doable in Java.

Re: Making the move from Scala to Go

#145
post #112
post #108

Earlier quoted context omitted.

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.

As simple as a distributed, horizontally scalable SQL database, perhaps? ( https://github.com/cockroachdb/cockroach ). Those dumb Go programmers and their toy programs ( https://quicknotes.io/n/1XB0 ).

The guys who wrote CockroachDB never, afaik, tried to write it in Scala, and never told us whether they miss flatMap, generics, or something like that.

They guys from Movio did; their problem domain is likely different.

Re: Making the move from Scala to Go

#146
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…

> but there's a reason why GOTO is considered to be brain cancer and pattern matching is generally considered to be great.

Look at any large C codebase and you will see plenty of goto statements to manage resource cleanup. The problem is using goto in place of structured control flow like loops and if/else. Statements like yours make it seem like there is a conceptual problem with a jump.

Re: Making the move from Scala to Go

#147
"..it felt quite empowering to have the confidence that, supported by type-checking and a few well-thought-out tests, my code was doing what it was meant to. "

Does this mean that on what software is "meant to do" type checking covers most test cases and only few additional is needed to ensure iy does what it's meant to do?

Re: Making the move from Scala to Go

#148

Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type infere…

The Scala compiler is indeed slow, mostly because it has to do a lot more work than the Java or Go compiler. However, in my experience Sbt's incremental compilation works well for small to medium sized projects. Beyond that we need a bigger hammer, and we're working on a parallel (and later, distributed) Scala compiler [1].

Full disclosure: I'm one of the founders.

[1] https://triplequote.com/hydra.html

Re: Making the move from Scala to Go

#149

Earlier quoted context omitted.

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

As long as you get your mutable code right. If there are any unintentional holes in your instantiate/operate/consume box...

Re: Making the move from Scala to Go

#150
post #144

Earlier quoted context omitted.

Its not go code fully. Its java that takes 3 mins. Go takes very less time like 3-4 secs. Multiple smaller services so we compile only what we change.

> Multiple smaller services so we compile only what we change. Also doable in Java.

sure. Never denied. But we are breaking apart that java code part by part. The docker build size is also very small as mentioned in the article. Our app involves lot of bandwidth so we good with smaller containers.
Post reply on HN