Live data from Hacker News

Making the move from Scala to Go

movio.co

131–140 of 378 posts

Re: Making the move from Scala to Go

#131
post #48

Obligatory "did you try running sbt ~ compile before you started complaining about the compile times" post. It's amazing how the tools for faster turnaround times exist-- the one thing the Scala community needs to do a better job of is clear, opinionated documentation. Also -- https://github.com/scala-native/scala-native -- watch that space.

Yes, first thing that crossed my mind. Scala is a very deep language, it was by far the language that took me the longest to learn.

Re: Making the move from Scala to Go

#132

Earlier quoted context omitted.

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.

Why? The code is still there even when a person leaves.

Re: Making the move from Scala to Go

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

Software can be complex without having very complex types

Re: Making the move from Scala to Go

#134

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

This is one of the extremely cool things about python. There's always one right way to do this, and it's usually pretty obvious. There's also quite clear, standard style guidelines, so code is generally formatted pretty much homogeneously, and tends to be a lot more readable than many other languages.

Per the Zen of Python, there should always be exactly one sensible way to do something, but unfortunately this is not often the case. List comprehension can be achieved just the same with functools, itertools, explicit for loops, etc.

That said, I do tend to have that mantra a little more present in my head when I'm working with Python.

Re: Making the move from Scala to Go

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

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 the code sane, such as "no chained ternary operators are allowed" ?

Re: Making the move from Scala to Go

#136

Earlier quoted context omitted.

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 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 can feel like a waste of time.

Re: Making the move from Scala to Go

#137
post #109
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…

OP is about Scala, where you write directly what you mean, without special operators: val usefulMetric = if (wantComplexCalc) { complexCalc(foo) } else { simpleCalc(foo) }

Well, that's only "directly what you mean, without special operators" if you come from a C style procedural background and have already internalized all the special operators you've included there, such as parenthesis and braces. Sure, that's most people, but that doesn't mean they aren't operators.

Re: Making the move from Scala to Go

#138

Earlier quoted context omitted.

Unfortunately sole code ownership increases the bus factor.

Why? The code is still there even when a person leaves.

Code is really hard to work with without the theory that surrounds it, and is alive in the people who worked on it.

Peter Naur - Programming As Theory Building http://pages.cs.wisc.edu/~remzi/Naur.pdf

Re: Making the move from Scala to Go

#139

Scala is an excellent language from a safety and design perspective. It's biggest flaw is the lack of a corporate sponsor and higher barrier of entry. Map, FlatMap, Options are all really great but hard to grok at first.

Thanks, glad you like it! We at Lightbend (my employer) don't think of ourselves as very corporate, but we definitely sponsor Scala development. My team is hard at work on Scala 2.13 (well, except the part of it that's commenting on HN stories).

Re: Making the move from Scala to Go

#140
[Scala team lead at Lightbend here]

I'm always eager to learn how we can improve Scala, especially as we kick of the Scala 2.13 cycle (hard at work on compiler performance and standard library improvements). Email is 'adriaan.at("lightbend.com")

Regarding Scala's growth, I will leave you with https://www.indeed.com/jobtrends/q-scala.html.

Post reply on HN