Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala vs Go

quora.com

Post reply on HN
Print view View original

71–80 of 109 posts

Re: Scala vs Go

#71

Post by psiclops »

strictfp wrote: post #41

Very similar to the c++ vs c debate. C++ has tons of arguably useful features. But these features also in a way distract from the task at hand - solving a problem. You risk ending up discussing the meta problem too much - how to write and organize code. C on the other hand is very basic, requires a lot of boilerplate and encourages re-implementation. But you are (subjectively) more likely to produce pragmatic code wh…

> "Worse is Better"

I wouldn't say that it is inherently worse to have a simple feature set. Sometimes less is more [0]

[0] https://commandcenter.blogspot.de/2012/06/less-is-exponentia...

Re: Scala vs Go

#72

Post by MrPowers »

mi100hael wrote: post #36
100k wrote: post #33

I'm learning Scala at my new job (previously worked in Ruby, Python, and long ago, Java and enjoy learning about functional programming). It's a fine language with a lot of great things about it...that get tossed the second you touch Java. It's wonderful to not have null. Except that you do anyway! My biggest complaint is that it is so multi-paradigm that different systems in our codebase have completely different st…

> It's wonderful to not have null. Except that you do anyway! If you hit a NPE in Scala, you're doing something objectively wrong. You should be wrapping any calls to Java libraries that may return null with Option().

I agree that null should generally be banned from Scala code, but your statement is a little too strong. I use Spark / Scala for big data applications and Option() is slower than null. From the Databricks Scala style guide: "For performance sensitive code, prefer null over Option, in order to avoid virtual method calls and boxing."

Re: Scala vs Go

#73

Post by sushisource »

ninly wrote: post #68

I'm curious about the claim (er, "observation") that At scale, the skill level of developers reading/writing/maintaining/testing code is going to be a normal distribution around the mean of "not expert." Has this been researched or shown in any formal way? Or have similar observations been formulated elsewhere?

I believe Google actually did some research that concluded something to this effect, and it was a big part of why they started pushing Go internally. Whether or not that's the right conclusion based on that data is debatable... I'd argue not.

Re: Scala vs Go

#74

Post by pjmlp »

sly010 wrote: post #56
pjmlp wrote: post #35

Earlier quoted context omitted.

I doubt that Go network libraries and crypto libraries are so well battle tested as Java ones, which Scala can take advantage of, specially taking into account the amount of JVM and library vendors.

Scala not having a single well defined networking library and having to revert to using Java is exactly why I prefer Go for networking. Gotta call a http endpoint in Go? https://golang.org/pkg/net/http/ Gotta call a http endpoint in Scala? https://www.google.com/search?q=best+http+client+library+in+scala Perhaps I just don't have enough experience with Scala and I don't know the best practices (maybe everyone just us…

Many of us love the polyglot nature of JVM and .NET, and don't mind using the best library, even if written in system language of the platform.

Re: Scala vs Go

#75

Post by saryant »

sly010 wrote: post #56
pjmlp wrote: post #35

Earlier quoted context omitted.

I doubt that Go network libraries and crypto libraries are so well battle tested as Java ones, which Scala can take advantage of, specially taking into account the amount of JVM and library vendors.

Scala not having a single well defined networking library and having to revert to using Java is exactly why I prefer Go for networking. Gotta call a http endpoint in Go? https://golang.org/pkg/net/http/ Gotta call a http endpoint in Scala? https://www.google.com/search?q=best+http+client+library+in+scala Perhaps I just don't have enough experience with Scala and I don't know the best practices (maybe everyone just us…

The java.net package already exists. And there's Netty, which is more battle-tested than likely any networking library save BSD's.

Re: Scala vs Go

#76

Post by strictfp »

psiclops wrote: post #71
strictfp wrote: post #41

Very similar to the c++ vs c debate. C++ has tons of arguably useful features. But these features also in a way distract from the task at hand - solving a problem. You risk ending up discussing the meta problem too much - how to write and organize code. C on the other hand is very basic, requires a lot of boilerplate and encourages re-implementation. But you are (subjectively) more likely to produce pragmatic code wh…

> "Worse is Better" I wouldn't say that it is inherently worse to have a simple feature set. Sometimes less is more [0] [0] https://commandcenter.blogspot.de/2012/06/less-is-exponentia...

I was refering to https://en.m.wikipedia.org/wiki/Worse_is_better , which does essentially say 'less is more'.

Re: Scala vs Go

#77

Post by strictfp »

eweise wrote: post #65
strictfp wrote: post #41

Very similar to the c++ vs c debate. C++ has tons of arguably useful features. But these features also in a way distract from the task at hand - solving a problem. You risk ending up discussing the meta problem too much - how to write and organize code. C on the other hand is very basic, requires a lot of boilerplate and encourages re-implementation. But you are (subjectively) more likely to produce pragmatic code wh…

Java was a way For Sun to sell more servers so they pushed it as application server technology.

But do you know who designed the server tech? Was it old mainframe people?

Re: Scala vs Go

#78

Post by [deleted] »

strictfp wrote: post #41

Very similar to the c++ vs c debate. C++ has tons of arguably useful features. But these features also in a way distract from the task at hand - solving a problem. You risk ending up discussing the meta problem too much - how to write and organize code. C on the other hand is very basic, requires a lot of boilerplate and encourages re-implementation. But you are (subjectively) more likely to produce pragmatic code wh…

[deleted]

Re: Scala vs Go

#79

Post by ovidnis »

sushisource wrote: post #73
ninly wrote: post #68

I'm curious about the claim (er, "observation") that At scale, the skill level of developers reading/writing/maintaining/testing code is going to be a normal distribution around the mean of "not expert." Has this been researched or shown in any formal way? Or have similar observations been formulated elsewhere?

I believe Google actually did some research that concluded something to this effect, and it was a big part of why they started pushing Go internally. Whether or not that's the right conclusion based on that data is debatable... I'd argue not.

Why not? It seems reasonable to me that as the number of people working on some piece of code grows the average skill will settle around "not an expert", whatever that means.

Re: Scala vs Go

#80

Post by fauigerzigerk »

orclev wrote: post #43
mi100hael wrote: post #15

> Scala code can be very dense and hard to grok at the early stages of learning. This seems to be the crux of his argument, and I think it's a rather poor one. I have used both Go & Scala professionally. Yes, it took less time for me to start writing real code in Go. However, I found Go's "simplicity" to be limiting and frustrating when it came to building production applications. Things like the weird split between…

It also confuses ease of reading with density of meaning. It presents the simplistic idea that the less dense statement is always the easiest to read, which might be true in isolation but it's almost always false in the larger context. It's pretty easy to prove this, simply ask yourself, would you rather read a quicksort implementation in C or assembly? C is certainly more dense in meaning, but it's also much easier…

>It also confuses ease of reading with density of meaning

He says more about that later and I find that part more interesting:

"Go code is explicit and the Scala code requires context to understand."

I believe he is saying that in order to understand a particular Scala expression you need more information from outside the immediate local context than in Go, i.e. information only available in type definitions.

I haven't thought about it enough to say whether or not I agree, but I think it is a very interesting hypothesis.

If it turns out to be true, it would support the claim that Go works better than more type centric languages whenever developers are less familiar with the codebase, irrespective of language proficiency.

I find it annoying that familiarity with the language and familiarity with the codebase keep getting conflated in these debates. They are completely seperate issues.

Post reply on HN