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

251–260 of 378 posts

Re: Making the move from Scala to Go

#251

Post by oelang »

jcadam wrote: post #209
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…

I've used Scala, Clojure, and Go. I found Scala to be too feature-rich for its own good. It was fun to write (Look at me! I just spent two hours figuring out how to compress this old Java 7 function into a one-liner in Scala!), but reading someone else's Scala was almost as mind-numbing as reading another programmer's C++. Go is... meh. Quick to learn, easy to write (and read), but you quickly hit a plateau as far as…

The way you describe your experience with Scala makes me think you only had a very superficial look at it.

At it's core Scala is very simple & the syntax is very regular, far more than Go or Java and a lot less complex than C++. It's the most expressive typed language on the JVM, so if you like to think in types & you're on the JVM it's your best option.

Clojure is untyped, I hear many people praising it but I don't know any big project done in Clojure. So if you're doing short-lived projects I'm sure it can shine but for software that will be around for more than 5 years I would stay away from it. Btw, if misused, just like Scala, Clojure code can be extremely cryptic.

Go likes it's superficial simplicity, syntactic irregularity & stubbornly refuses to accept that PL design has evolved since the 80-90ies, but I'm sure it's appealing to people who are used to languages from that era.

Re: Making the move from Scala to Go

#252

Post by aninhumer »

tel wrote: post #203
aninhumer wrote: post #161

Earlier quoted context omitted.

> At least with a function `a -> b` might be named `in -> out`, but with a Profunctor there isn't even that intuition. What about: dimap :: (newIn -> in) -> (out -> newOut) -> p in out -> p newIn newOut

With profunctors there's not necessarily anything going in or out and especially not necessarily and notion that the thing going in produces a thing going out. That's all roughly true with one kind of profunctor, a function arrow, but not true in general. For instance, data Counterexample a b = Cx (Set a) b is (very, very, very nearly [0]) a profunctor, but a isn't necessarily "going in" and b isn't necesssarily "com…

I'm not sure I see how the intuition is bad here? What would the lmap implementation for your (Set a) example be if not equivalent to the (a -> Bool) case? And how is that not an example of data "going in"?

More generally even if there are Profunctors for which this analogy isn't perfect, I feel like the intuitive type names are still more useful than random letters. Especially for a relatively advanced concept like Profunctors, for which I expect pretty much all users to be comfortable with the idea that a type variable does not necessarily imply that concrete values of that type will exist.

Re: Making the move from Scala to Go

#253

Post by edejong »

pjmlp wrote: post #227
edejong wrote: post #199

Earlier quoted context omitted.

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 ha…

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." -- Alan Kay, The Computer Revolution hasn't happend yet — 1997 OOPSLA Keynote

Could you explain how exactly this quote is applicable to Dijkstra's quote? Which part do you think is arrogant?

Alan seems to make an overly broad statement, which is funny, but also weak.

Re: Making the move from Scala to Go

#254

Post by gpderetta »

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

what about:

  usefulMetric = wantComplexCalc == false ? simpleCalc(foo)
               : complexity

Re: Making the move from Scala to Go

#255

Post by eternalban »

geodel wrote: post #250
eternalban wrote: post #224

And they could have just used Java from the beginning.

And how do you propose to offset the benefit of smaller image size and lower memory usage?

I see. Smaller image size and lower memory usage was the critical factor informing the decsion to use Scala and not Java?

If we're talking server provisiong cost bread ($) I think factoring in the costs of stack switch, code rewrites and salaries should be on the table too!

p.s. Have been writing Go code since the day it was released. My comment has nothing to do with their decision du jour.

Re: Making the move from Scala to Go

#256

Post by lentil »

lazyjones wrote: post #175
unoti wrote: post #52

I have a simple question. In the article they mentioned they had a concurrency issue with a timed buffer that they later neatly solved with go channels and goroutines. They said that they solved the problem in Scala by moving to the actor model, but that required importing Akka into their project and training everyone how to use Akka. My simple question is: couldn't they have achieved the heart and soul of the actor…

I found the Go solution for that issue a bit odd - channels aren't for data processing, they're synchronisation primitives. Using them the way they did in the article ruined the piece for me, since it reads like a rather uninformed decision now.

Are you sure they aren't intended for data processing? I've never heard that claim before, and the Go documentation seems to have a lot of examples of using channels in that way. (https://blog.golang.org/pipelines, for example; or https://tour.golang.org/concurrency/2).

Re: Making the move from Scala to Go

#257

Post by galacticpony »

todd8 wrote: post #240
galacticpony wrote: post #205

Earlier quoted context omitted.

I think it is interesting that you left out the very next few sentences, which provide very relevant context: "I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque." While I agree with the general sentiment, it's very important to…

I agree with Dijkstra, the looping constructs of FORTRAN's DO and ALGOL 60 were too baroque. Dijkstra's comments were written in 1977, at that time FORTRAN IV and ALGOL 60's loop semantics were a mess and were common sources of errors. Without qualification, Dijkstra was one of the greatest computer scientists in our field's short history. While I don't agree with every single one of his ideas, I would encourage budd…

I know about Dijkstra.

I didn't say Dijkstra was talking out of his ass in this case. I'm saying you often can't tell when people like him are talking out of their ass, as they sometimes do. Who would think the inventor of all these algorithms would ever utter a half-formed thought, on a whim? Unthinkable! Yeah... no.

Another distinction you fail to see is that somebody who is great at finding the best or optimal algorithms (i.e. a great theorist) isn't necessarily a productive programmer. To the contrary, perfectionism and productivity are at great odds.

Dijkstra was heavily at odds with real-world programming as it was done, to the point of isolating himself with his work. If we followed his opinions on how to program, we wouldn't get much of anything done.

Re: Making the move from Scala to Go

#258

Post by coldtea »

majkinetor wrote: post #180
ivanhoe wrote: post #171

Earlier quoted context omitted.

IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do tha…

Great comment. Particularly > Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through. I stopped contributing to one Powershell repository because author thought that ps is hard and he wanted Get-Process. I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful Particulary > Also keep…

>I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful

Sounds like it was disrespectful too.

Re: Making the move from Scala to Go

#259

Post by PopsiclePete »

oelang wrote: post #251
jcadam wrote: post #209

Earlier quoted context omitted.

I've used Scala, Clojure, and Go. I found Scala to be too feature-rich for its own good. It was fun to write (Look at me! I just spent two hours figuring out how to compress this old Java 7 function into a one-liner in Scala!), but reading someone else's Scala was almost as mind-numbing as reading another programmer's C++. Go is... meh. Quick to learn, easy to write (and read), but you quickly hit a plateau as far as…

The way you describe your experience with Scala makes me think you only had a very superficial look at it. At it's core Scala is very simple & the syntax is very regular, far more than Go or Java and a lot less complex than C++. It's the most expressive typed language on the JVM, so if you like to think in types & you're on the JVM it's your best option. Clojure is untyped, I hear many people praising it but I don't…

Go is a language that is a bit tedious to write, no doubt about that, but it's very easy to read. I spend a lot of my time reading other people's code and I really appreciate that.

The fact that Scala as a language allows something like SBT to not only be created, but accepted, means I don't want anything to do with it.

I've suffered long from the Ruby ecosystem's mentality of "look at what I can do!" of self-serving pointless DSL's and frameworks and solemnly swore to myself to stay away from cute languages that encourage bored devs to get "creative".

It's about trade-offs, I guess. Go definitely appeals to a lot of people, and not all of us are unaware of the amazing "progress" that has been made in the 80's and 90's. Awesome progress that brought us Java, SOAP, C++, Javascript-on-the-server, and a slew of other tech some of us want to stay far, far away from.

Re: Making the move from Scala to Go

#260

Post by coldtea »

gpderetta wrote: post #254
jiaweihli wrote: post #126

Earlier quoted context omitted.

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

what about: usefulMetric = wantComplexCalc == false ? simpleCalc(foo) : complexity

Doesn't look much better.
Post reply on HN