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

121–130 of 378 posts

Re: Making the move from Scala to Go

#121

Post by tel »

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…

Scala got a boost when it was just getting started by being a "Better Java". Now it's less able to stand on that value proposition and its losing supporters.

Honestly it was a great adoption strategy.

Re: Making the move from Scala to Go

#122

Post by pron »

lacampbell wrote: post #105
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'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere. And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

There are two problems with this argument. First, brilliance in code is not a property of what linguistic abstractions the code makes use of, but the elegance of the algorithm and engineering. I sincerely doubt that no brilliant code had been written prior to the introduction of your favorite linguistic abstractions. Second, even supposing you're right, what difference does that make? If your code's maintainers are dumb, do you think that you could change this reality by making life harder for them, or is it your job to adapt yourself to the reality of the system you're a part of? When creating something for dumb people to use, is it a sign of good craftsmanship to make it harder for them to work with?

Re: Making the move from Scala to Go

#123

Post by mahyarm »

solidsnack9000 wrote: post #88
mahyarm wrote: post #25

Earlier quoted context omitted.

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?

From the start they decided to ship with a standard formatter / linter for example. A standard cross platform build system, optimized for build speed from the start, etc. I think a better word would of been a 'top priority'.

Re: Making the move from Scala to Go

#124

Post by mahyarm »

Cyph0n wrote: post #30
mahyarm wrote: post #25

Earlier quoted context omitted.

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…

Compile times are a problem, yes, but tooling is not an issue. sbt is a solid build tool in my opinion. Regarding the compiler, the Scala team has that as their number 1 priority right now. There is major work being done on building the compiler from the ground up [1]. Also, there is scala-native, which aims to provide AOT compilation for Scala code [2]. Scala vs. Go is an interesting comparison, but I think that the…

I come from the swift world, where a lot of their scala issues resonate with me. The article also mentioned tooling being an issue for them.

They have a lot of decisions that make a lot of sense in large code project context, which google has plenty of. Stuff like KISS, fast code speed, standard formatting & build tooling and so on.

I haven't worked with either language, so take what I say with a grain of salt.

Re: Making the move from Scala to Go

#125

Post by kelnos »

geoka9 wrote: post #69
kod wrote: post #44

Earlier quoted context omitted.

No, there's a huge difference in quality of programmers. I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. I've been on other teams where some of the guys still couldn't understand closures after 6 months.

> I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. Personally, I like to measure things like that by how fast a team/developer can get up to speed on maintaining an already existing non-trivial codebase in the language. Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Sca…

I don't think I'd agree with that. I tend to learn languages by looking at what others have done. Doing something from scratch in a new language with unfamiliar libraries is really hard. Digging into someone else's codebase -- assuming they've done a good job at writing clean code and avoiding being "clever" -- to make small changes is way easier when you're first starting out.

Re: Making the move from Scala to Go

#126

Post by jiaweihli »

kbenson wrote: post #34
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…

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

Re: Making the move from Scala to Go

#127

Post by nemothekid »

lacampbell wrote: post #105
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'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere. And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

>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 point do you have to wonder - is the gain in expressiveness for a single programmer worth the cognitive cost of the multiple programmers who have to parse that code.

I'd imagine the answer is no - especially for companies that spend more time iterating and patching based on customer feedback than actually designing and architecting systems. My belief is that expressive languages have their place but companies are far more likely to build their software in a "patch-test-iterate" environment which favors less expressive languages.

Re: Making the move from Scala to Go

#128

Post by jiaweihli »

lacampbell wrote: post #106
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

That's why I'm a proponent of code ownership. We should be coding to each others interfaces instead of constantly poking around in the same shared codebase. It just leads to pointless re-writes and low quality - a tragedy of the commons. https://www.visualstudio.com/en-us/articles/devopsmsft/code-...

Unfortunately sole code ownership increases the bus factor.

Re: Making the move from Scala to Go

#130

Post by jiaweihli »

_Codemonkeyism wrote: post #104

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…

If you ever find yourself working in JS and want Options, I've got you covered: https://github.com/jiaweihli/monapt
Post reply on HN