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

151–160 of 378 posts

Re: Making the move from Scala to Go

#151

Post by kkoomi »

jiaweihli wrote: post #126
kbenson wrote: post #34

Earlier quoted context omitted.

> aversion to certain shortcuts like ternary operators. > They don't understand that unclear code is probably the number one cause of technical debt. At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment , I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from usin…

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

That's just laziness on part of the refactorer. At that point, you need to use an outer if-else statement. Ternary operators are confusing when nested.

Re: Making the move from Scala to Go

#152

Post by MrBuddyCasino »

pacala wrote: post #117
mdasen wrote: post #63

Earlier quoted context omitted.

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…

Not following Java very closely and using Scala as a better Java. Is there hope to get case-class POJOs in Java itself?

Its scheduled for Java 9 or 10, not sure which.

Re: Making the move from Scala to Go

#153

Post by bsaul »

Wonder where they'll go once their codebase becomes crippled with interface{} type and nil pointers check, and they stop using chanel to return to mutex for performance reasons, or more control.

Note : sounds snarky, but it's an honest question i find asking to myself after having tried many server side techs and feeling limited with go.

Re: Making the move from Scala to Go

#154

Post by izacus »

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…

Thing is, a lot of these nice things of Scala can you now get with Kotlin - with better IDE support, better readability, better compile times and more seamless interoperability with existing Java libraries.

Re: Making the move from Scala to Go

#155

Post by Sphax »

bsaul wrote: post #153

Wonder where they'll go once their codebase becomes crippled with interface{} type and nil pointers check, and they stop using chanel to return to mutex for performance reasons, or more control. Note : sounds snarky, but it's an honest question i find asking to myself after having tried many server side techs and feeling limited with go.

Probably nowhere because 1) never happens 2) is a non-issue and 3) too probably 99% of the time.

Re: Making the move from Scala to Go

#156

Post by Sphax »

joshlemer wrote: post #64
tylerpachal wrote: post #58

Earlier quoted context omitted.

Could you explain this a little bit? I am just getting into Scala, usually I use `sbt run` and `sbt test` while I am working, then `sbt dist` to package my production app. What does `sbt ~ compile` do ?

If you run `~` before any command, sbt watches the directory for any source changes, and on detecting source changes, redoes the command. So `sbt ~compile` will re-compile any new sources as soon as they are saved.

Wait, how does that help build time exactly ? It may help with the perceived build time, but your CI builds are still taking the same (long) time.

Re: Making the move from Scala to Go

#157

Post by mhotchen »

jiaweihli wrote: post #141
kbenson wrote: post #135

Earlier quoted context omitted.

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…

> the rule would be no ternary operators

Why not "no nested ternary operators"?

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

Why not "keep unwrapped if conditions on a single line"?

> Early returns simplify short circuiting logic unless your function becomes too long

Why not "keep functions short"?

> Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy

Why not "only use conditionals on boolean values"?

I'm not saying your rules are right or wrong, I actually follow a couple of them myself, but your wording implies that other people are simply not following rules, or their rules have a lot of nuances and special cases, but the reality is more likely that their rules are different.

Ultimately we all make different connections and form different patterns in our head. As long as a team can agree on a code style, within a few months everyone starts developing the same cognitive patterns.

Re: Making the move from Scala to Go

#158

Post by tymm »

lkrubner wrote: post #57

Since they cite me (and my essay from 2014) as part of their decision making process, I want to throw in 2 cents here. They ended up deciding on Go, whereas I have ended up preferring Clojure, yet I agree with a lot of what they say, so I'll try to clarify why I ended up with a different decision than what they made. I understand what they mean when they write: I think the first time I appreciated the positive aspect…

Can you elaborate on why you think that Clojure has a higher level of composability than a static typed language like Scala?

Re: Making the move from Scala to Go

#159

Post by aninhumer »

joejev wrote: post #146
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…

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

Sure there are some cases in C where you want a particular control flow that the language doesn't allow, and goto is the best solution in those cases.

But all the examples of this that I've seen are still structured it's just that the language isn't able to express that structure. The most common examples are jumping out of nested loops (better solved by allowing named loops so you can use break/continue) or jumping immediately to error handling logic (better solved by exceptions, or even just simplistic try/throw/catch).

I do think there's a conceptual problem with arbitrary jumps.

Re: Making the move from Scala to Go

#160

Post by jerven »

andrewvijay wrote: post #94
abc_lisper wrote: post #93

Earlier quoted context omitted.

More importantly, how much time did it take to rewrite code that took 15m to compile! Are the machines working for the man, or the man for the machines ;)

3 person effort for 4 months. Compile time was just one of the advantages though.

As this is the 3rd language in your code base, 1st there was java, then there was Scala and now GO. I do hope all Scala code is gone by now! I assume this decision and investment was extremely well supported, but that is not obvious from your blog post and supporting comments here.

So 12 months of effort -> at Bay area salaries and costings that is in the order of magnitude of 300,000USD. Your parent company had 6.6 million NZD profit last financial year. So for investing around 5% of the total profit of the larger group your mayor benefit is reduced compile times. Plus some other second system benefits.

That is a rather expensive decision to have taken, and I think if you had been forced to do a proper ROI investigation before hand you would not have gotten that. In my experience when doing these calculations and getting the numbers down it is never the financially wise choice to change languages but instead actually fix the pain points that people have with the language and most often the actual project setup. It is only when a language change is incremental, adds a key feature or is a market requirement e.g. for deploying on certain devices that a new language makes financial sense.

I am not judging your GO decision over Scala as a better language but I am judging your management layer for doing this. Especially as it sounds like from other posts that GO is now 1 more language to support in your company. Increasing certain costs outside of yours as a team in cross team training opportunity, support and monitoring etc...

Of course sometimes changing language is like changing from speaking French to Italian in the office and hoping that office politics will disappear... Been there done that, it did not work out as hoped by the developers.

Post reply on HN