Live data from Hacker News

Making the move from Scala to Go

movio.co

191–200 of 378 posts

Re: Making the move from Scala to Go

#191
post #188

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". If you ever wonder this, then it's definitely a problem with your code and not the reader. Code that cannot be easily read and understood by others is worthless in any commercial setting.

If you're too numb or stubborn to learn the tools that your programming environment provides for writing higher quality code, I have little sympathy and would suggest that such a person fond another line of work.

If, for instance, someone were writing C# and insisted on hand-rolling for loops in all cases[1], because LINQ is "too hard", that's them being lazy and unwilling to invest a tiny amount of effort in learning more effective methods.

[1] There are some cases where it's more performant to use a plain foreach or bare for, but unless you're in tight loops or dealing with ginormous collections, it's a premature optimization.

Re: Making the move from Scala to Go

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

Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider: users.filter(_.active).map(_.email) to be easier to read (and not a pain in the ass to type) than: emails := make([]string, 0) for _, u := range users { if u.active { emails = append(emails, u.email) } } return email The first style is more exp…

> Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM.

With more features (TP 7)!

Re: Making the move from Scala to Go

#193

My company also have a lot of problems with Scala, both technical and non technical ones, but so far we have managed to control it: - As for slow compilation times, incremental building helps a lot. - Intellij works most of the time, and if it doesn't a few type annotation will fix it. - It's very hard to find people with Scala experience. We have given up on finding those and decide to train people from the beginnin…

+1 for "If it compiles, it works" .... been there done that ... multiple times !!! And yes in the beginning the feeling of "it works on the first run" was just strange and it get me some time getting used to it

Re: Making the move from Scala to Go

#194
post #191
post #188

Earlier quoted context omitted.

> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". If you ever wonder this, then it's definitely a problem with your code and not the reader. Code that cannot be easily read and understood by others is worthless in any commercial setting.

If you're too numb or stubborn to learn the tools that your programming environment provides for writing higher quality code, I have little sympathy and would suggest that such a person fond another line of work. If, for instance, someone were writing C# and insisted on hand-rolling for loops in all cases[1], because LINQ is "too hard", that's them being lazy and unwilling to invest a tiny amount of effort in learnin…

Or working in game development with low latencies to achieve high frames per second.

Re: Making the move from Scala to Go

#195
post #168

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

For completeness: https://www.indeed.com/jobtrends/q-scala-q-golang.html

Or for those who don't call it "golang":

https://www.indeed.com/jobtrends/q-scala-q-golang-q-go.html

Re: Making the move from Scala to Go

#196
post #117
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?

Project Lombok already does that, you should check it out: https://projectlombok.org/

Re: Making the move from Scala to Go

#197
post #98
post #50

Earlier quoted context omitted.

When I was first introduced to scala my very favorite thing was the existence of map. I'd been using java for a while and missed it dearly

Not allowed to use Java 8?

Didn't exist at the time. While I still prefer scala to java 8, had the latter been available at the time I likely never would have dabbled in scala in the first place, if that makes sense

Re: Making the move from Scala to Go

#199

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 (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD.

EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]:

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. "

[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...

Re: Making the move from Scala to Go

#200
post #84

Earlier quoted context omitted.

And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.

Fair enough - but I'll offer this: + Any decent developer can read decent code in Java or whatever normal language and get along just fine. + Only a few people can deal with Scala - and even fewer if there's a log of specific project Scala weirdness used in a particular program. So sure - among a narrower set of 'Scala friendly' developers, and possibly within that even narrower set of people familiar with the 'Scala…

That's not what you said. You said others, not most people. The most important aspect is who you surround yourself with. For instance the scala folks at Verizon basically live in the zone you're talking about and it is fine for them even though half the time it makes no sense to me
Post reply on HN