Live data from Hacker News

Making the move from Scala to Go

movio.co

271–280 of 378 posts

Re: Making the move from Scala to Go

#271
post #251

Earlier quoted context omitted.

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

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

FWIW, we agree and continue to use Gradle, despite making investments in Scala.

Re: Making the move from Scala to Go

#272

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

I don't think that Go is a good language to compare with Scala. (I do like Go, though.) The two languages could not be more different in philosophy. Scala is maximalist - you can do things many ways, you can call java, you can have tremendously intricate types, etc. Go is minimalist - there are just enough tools to get by, and sometimes it feels like you are missing one. My experience with Scala is that you spend mor…

Thanks for your balanced reply. Sadly, some people see it as a badge of honor to write super clever code that's essentially write-only, and Scala somehow triggers this in them :-)

We, as the Scala community, play an important role in shaping the culture of programming in Scala as one that embraces simplicity as the true elegance, maintainability and testability, friendliness and openness to criticism. The language will remain flexible (though we're always looking to remove warts), it's really up to your company culture to decide how to use it (which is different for different teams over time).

Many big players, such as Twitter, have done a great job with that (and continue to do so).

Re: Making the move from Scala to Go

#273
post #251
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…

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

I worked with it daily for 2 years and also took Odersky's Coursera courses on Scala. I liked it more than Java (7), though I find the syntax aesthetically offensive (and I realize that's subjective). Ada (I worked in an Ada shop for 3 years before moving to the JVM) managed to have a robust type system without introducing the sort of syntax wtf-ness that Scala seems to need.

I actually recommended against using Scala at a later job simply because I thought the learning curve would be beyond most of the people I was working with (I didn't phrase it quite like that when mgmt asked me for my opinion, of course). Learning to write idiomatic Scala takes time. In that regard it's an expensive language to use unless you hire folks who already have experience with it.

As far as Clojure's dynamic typing goes, you can use libraries like plumatic/schema to add some checking where you need it (interfaces, etc), and for whatever reason I tend to have less trouble (as far as runtime type issues go) with Clojure than I do with Python or Ruby.

But hey, no language is perfect. I kind of wish Haskell clicked for me the way LISP seems to, since on paper it seems to check all the boxes -- but I just can't seem to get very proficient with it (or I'm just not willing to invest the time at this point).

Re: Making the move from Scala to Go

#274
post #251
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…

> Clojure is untyped, I hear many people praising it but I don't know any big project done in Clojure.

Not sure your standard of big, but:

1. Most of Climate Corporation's (https://climate.com/) backend is written in clojure and they deal truly massive amounts of imaging data and parse/munge it to be useful for their applications.

2. Various places using clojure for various things without details but some of them are likely big https://clojure.org/community/companies and http://dev.clojure.org/display/community/Clojure+Success+Sto....

I'm sure people with first hand experience will chime in too.

Re: Making the move from Scala to Go

#275
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…

Actors should be in a process no? If it's in a thread then it'll take the main process down with it. Erlang's BEAM VM every actor is in it's own process. So if something goes bad then it can be restarted via supervisor. Scala is on JVM and JVM isn't built with concurrency in mind and I think Erlang's BEAM is too good at this. Akka is gimped too, you have to write actor a certain way iirc other wise it takes over the…

Elixir makes Erlang look beautiful! You should check it out!

Re: Making the move from Scala to Go

#276

Having this smartness disparity between devs is really bad for team dynamics, and complexity leads invariably to this. More and more I believe this to be a profound truth.

This seems like an argument for the lowest common denominator. What should programmers who enjoy working with more powerful abstractions do?

  >> What should programmers who enjoy working with more powerful abstractions do?
Work on teams where the lowest common denominator is higher.

Re: Making the move from Scala to Go

#277
"Part of my frustration with Scala (and Java) was the feeling that I was never able to get the full context on a given problem domain, due to its complexity."

This. Same with any other kitchen sink language.

Re: Making the move from Scala to Go

#278

Earlier quoted context omitted.

I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks. But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an…

"I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks." It still seems intellectually dishonest to leave it out. Clearly, what Dijkstra in 1972 considers too "clever" may in fact be tools that are now basic buil…

"Programmers prefer loops like Algol":

Yes, programmers prefer it, but the general structure:

`for (init-statement ; boolean-continuation-expression ; iteration-statement) statement;` is syntactic sugar for a specific imperative process (with the iteration and ending expression appended at the end of the block). It does not generalize to other imperative processes, it cannot be transformed into a meaningful expression and it invites 'clever' programmers to do 'too much' in the various for-clauses.

Wrt to LISP, do you mean this part? That seems to align well with my standpoint: use very few basic principles and be stable.

"The third project I would not like to leave unmentioned is LISP, a fascinating enterprise of a completely different nature. With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts."

Re: Making the move from Scala to Go

#279

In my experience, the larger your codebase, the more you appreciate these features: - a strong type system - a pure functional language so you have referential transparity - an IDE that helps you with refactoring If your project is small than you can do without all of those, actually they might even slow you down. When I read the article, I get the feeling that this particular team was working on a small codebase.

The author also complains about the sub-optimal IDE experience with Scala and then says he moved to a langage that has none …

Re: Making the move from Scala to Go

#280
post #158

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…

Can you elaborate on why you think that Clojure has a higher level of composability than a static typed language like Scala?

That is a large subject, for sure. It deserves a good essay. I'll try to write something tonight. I'll post it to my blog and I'll leave a note here.
Post reply on HN