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.
Making the move from Scala to Go
131–140 of 378 posts
Re: Making the move from Scala to Go
#132Earlier 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.
Re: Making the move from Scala to Go
#133Earlier 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 ).
Re: Making the move from Scala to Go
#134As 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.
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
#135Earlier 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);
Re: Making the move from Scala to Go
#136Earlier 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…
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
#137Earlier 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) }
Re: Making the move from Scala to Go
#138Earlier quoted context omitted.
Unfortunately sole code ownership increases the bus factor.
Why? The code is still there even when a person leaves.
Peter Naur - Programming As Theory Building http://pages.cs.wisc.edu/~remzi/Naur.pdf
Re: Making the move from Scala to Go
#139Scala 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.
Re: Making the move from Scala to Go
#140I'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.