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

201–210 of 378 posts

Re: Making the move from Scala to Go

#201

Post by 16bytes »

bad_user wrote: post #120

Some notes: - the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual f…

I don't understand the claim that Akka actors are both impure and non-deterministic.

If your actor is communicating only through its inbox, then it is both pure and deterministic. Given the same set of messages in the same order, you arrive at the same actor state. Sure, you can do wacky things with side-effects, but that's not akka's fault.

> in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual functional programming

This sounds a lot like the "no true Scotsman" fallacy. I'm not attacking your argument here, but perhaps you could expound upon that first point and clarify.

Re: Making the move from Scala to Go

#203

Post by tel »

aninhumer wrote: post #161
tel wrote: post #118

Earlier quoted context omitted.

I mostly agree with you, but I also think a bit part of what Haskell-like FP shows is how often your code is invariant to so many things that the variables no longer have any sense to them whatsoever. That doesn't really excuse badly named variables when that doesn't hold. It's more that it's something sort of novel to a lot of Haskell-like programmers and so we all get excited about it and probably overdo it somewha…

> 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 "coming out".

[0] It's a profunctor if a is finite. You can handle the infinite form by writing it as `data Cx a b = Cx (a -> Bool) b` which is equivalent to what I wrote when `a` is finite... but it also makes it a little easier to pretend that a is "going in" even if that's a bad intuition.

Re: Making the move from Scala to Go

#204

Post by andrewvijay »

jerven wrote: post #160
andrewvijay wrote: post #94

Earlier quoted context omitted.

3 person effort for 4 months. Compile time was just one of the advantages though.

As this is the 3rd language in your code base, 1st there was java, then there was Scala and now GO. I do hope all Scala code is gone by now! I assume this decision and investment was extremely well supported, but that is not obvious from your blog post and supporting comments here. So 12 months of effort -> at Bay area salaries and costings that is in the order of magnitude of 300,000USD. Your parent company had 6.6…

I'm sorry we never used Scala.it was a pure Java code base.

Re: Making the move from Scala to Go

#205

Post by galacticpony »

edejong wrote: post #199
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. "…

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 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 take anything Dijkstra says with a huge grain of salt. He was a mathematician first and foremost. He obsessed about things like a mathematician. Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.

Re: Making the move from Scala to Go

#206

Post by DrBazza »

Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. Even if the complaints are always generics and error handling.

Re: Making the move from Scala to Go

#207

Post by virtualwhys »

koevet wrote: post #168
adriaanm wrote: post #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 .

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

Well, more accurately would be to compare Scala to other languages[1] that operate in the same space (OO/FP).

[1] https://www.indeed.com/jobtrends/q-scala-q-haskell-q-ocaml-q...

Re: Making the move from Scala to Go

#208

Post by misja111 »

rubenv wrote: post #195
koevet wrote: post #168

Earlier quoted context omitted.

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

The extra keyword 'go' that you added will return all job postings that have any occurrence of the word 'go' in their description. See for another example: https://www.indeed.com/jobtrends/q-scala-q-golang-q-descript...

Re: Making the move from Scala to Go

#209

Post by jcadam »

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 personal productivity goes. I can see the value when working on large teams, but on my personal projects (for which I have limited time) my own productivity is paramount (not to mention I want a language that's fun to use) :)

Thus I've found Clojure is my ideal language for the time being. It strikes a good balance between power and simplicity (and at this point I find it more readable even than Go ).

Re: Making the move from Scala to Go

#210

Post by nunobrito »

unscaled wrote: post #174
nine_k wrote: 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…

The second example is vastly more readable in terms of understanding what it is supposed to do.

I mention this as neither a programmer on either Scala nor Go.

If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explanatory for an outsider when reading it.

Post reply on HN