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

41–50 of 109 posts

Re: Scala vs Go

#41

Post by strictfp »

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 which will solve your problem.

Scala is the kitchen zink of languages, i could elaborate but I don't even know where to begin.

Go is very simplistic and architected to solve some recent problems. It's easy to write high concurrency, low latency apps with minimal startup costs. Perfect for microservices. And it explicitly avoids certain complicating features such as generics, while still catering for its use cases by supporting code generation and compile-time constant computation.

Go is the rise of New Jersey Style. All developers tormented by c++,ORMs,Java EE,Soap et al join ranks to show the world that "Worse Is Better".

A funny thing is that go is very similar in style to early Java, and I believe that Gosling et al did have the same mindset as Thompson and Pike. But somehow Java got overrun by the enterprise guys, and I don't know where they came from. Does anybody here know maybe?

Re: Scala vs Go

#42

Post by TeeWEE »

TeeWEE wrote: post #39

Scala is a very complex languages, allowing tons of construct. And multiple ways to code anything. In any serious, bigger team project, you don't wanna use Scala imho. Not forgetting the super ugly stack traces. If you really need functional programming, use a more functional language. If you need speed, consistent code, and lots of developers. Use golang. Its simplifies software engineering. Also if forced to use th…

  def doSomething():Unit = {...}
  def doSomething:Unit = {...}
  def doSomething() = {...}
  def doSomething = {...}
  def doSomething() {...}
  def doSomething {...}

Re: Scala vs Go

#43

Post by orclev »

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 to read precisely because of that denseness.

I'm not a fan of Scala by any means, I think it suffers from a lot of the same problems C++ has, but I'd still take it over Go any day. In an effort to be easy to learn Go rejects any non-trivial concepts in the language leading to a language that makes expressing complicated concepts complex and trivial concepts verbose. Go is a language predicated on the idea that C is very nearly the pinnacle of language design, if only it hadn't included those complicated pointer things, and the only thing that really held it back was insufficient tooling. It rejects modern languages as unnecessarily complicated, and instead stipulates that instead of a complex language, it's your code that should be complex.

Re: Scala vs Go

#44

Post by yogthos »

I like Clojure for the same reasons. The simplicity and consistency of the language can't be overstated when it comes to writing maintainable code.

Re: Scala vs Go

#45

Post by mi100hael »

willvarfar wrote: post #10
danpalmer wrote: post #2

Would be interesting to get a gauge on how many bugs are typical in code in each language. From what I've heard Go code features a comparable number of bugs to Python per line of code. But far more lines of code. I don't know how that compares to Scala but would be very interested to know.

Complete tangent, but I must say that since I recently started using pycharm it has really caught most of the obvious typo and uninitialized bugs and my python code is really crashing surprisingly rarely as I prototype to death. Just saying in case there are others who haven't been trying modern python tooling and don't know that you can get real close to a compiled language type safety certainty these days before yo…

I get where you're coming from, but relying on an IDE for safety is a recipe for disaster. What happens when you just quickly pop open that file in on a shell to make a small change and fat-finger something? What happens when a different developer decides to use vim for everything? I used Python extensively for years and it's still my scripting language of choice, but to use it to build something safe in a business-critical situation requires an obnoxious number of tests, half of which are basically just type checks.

Re: Scala vs Go

#46

Post by jcdavis »

etaty wrote: post #17

The scala example is plain wrong. import play.api.mvc.RequestHeader def getUserId()(implicit request: RequestHeader) = { request.cookies.get("uid").map(_.value.toLong).filter(_ > 0) } Return type is missing, it will throw exception (toLong).

function return types are not required in scala, although every style guide I've seen requires them for any non-trivial function

Re: Scala vs Go

#47

Post by mi100hael »

geodel wrote: post #8

Scala is half a decade older than Go and has lead in big data infrastructure projects. Go has lead in container management infrastructure. May be that's their niche areas. I would be interested in seeing when they are applied in other's domain and how good/bad they really are.

> Go has lead in container management infrastructure.

That's a yardstick I didn't realize anyone was using.

Re: Scala vs Go

#48

Post by nickik »

In this sort of comparison Clojure looks quite good I think. It gets the full power of the JVM and ecosystem plus the full power of Lisp macros if you really need it.

Normally, it's a small orthogonal language with a highly typical 'Clojure' style of writing programs.

For people who like Go, they can easily switch to Clojure without relearning Concurrency stuff. They can use core.async just as Go-blocks. To make it even easier you don't have to pass around pointers ever, you can just pass around to references to immutable data or safe reference type.

Re: Scala vs Go

#49

Post by geodel »

agentgt wrote: post #21
ryanslade wrote: post #20

Earlier quoted context omitted.

I've been playing around with OCaml a fair bit in my spare time too. I've been using Go at work full time for about 4 years so that's my main comparison. I love OCaml as a language but the ecosystem is really pretty bad. There is just too much fragmentation and lack of libraries. I would have expected more from a language that is over 20 years old. Don't get me wrong, I want it to succeed since I agree it has a reall…

> Don't get me wrong, I want it to succeed since I agree it has a really nice mix of features.. I just have my doubts given its track record so far. While I agree... Javascript is also just as old and arguably more fragmented (with the exception of jQuery). That being said perhaps unlikely but OCaml may make a massive comeback just like Javascript did (particularly if for some reason Rust fails which I doubt).

Javascript has web giants' backing who made it work and well enough to write sophisticated frontends like webmails etc. OCaml has Jane street and may be a couple more using it as secondary language for some applications. I don't think it is going to catch up big time.

Re: Scala vs Go

#50

Post by mi100hael »

jcdavis wrote: post #46
etaty wrote: post #17

The scala example is plain wrong. import play.api.mvc.RequestHeader def getUserId()(implicit request: RequestHeader) = { request.cookies.get("uid").map(_.value.toLong).filter(_ > 0) } Return type is missing, it will throw exception (toLong).

function return types are not required in scala, although every style guide I've seen requires them for any non-trivial function

I only use them on methods/vals that are intended to be publicly used just so I don't inadvertently change the type of something and break someone else's code. Within private methods, it doesn't really matter.
Post reply on HN