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

31–40 of 109 posts

Re: Scala vs Go

#31

Post by sly010 »

Does it have to be one or the other? They are suitable for different things.

You will find it hard to write an enterprise level application with complex domain logic in Go. Go is low level. Scalas type system on the other hand is very well suited for that.

Go's standard library around networking and crypto makes it the best language of choice for pretty much anything network related. Scala doesn't even come close.

My opinion in 2017 is Scala and Go (or Go and Scala) _are_ the two best programming languages out there. Learning both is worthwhile and _together_ they cover a very large set of use-cases.

Re: Scala vs Go

#32

Post by was_boring »

MrBuddyCasino wrote: post #9
chipz wrote: post #7

One thing that I like about Scala is that we can use Java Mission Control to analyze how our code (to the 'method' level,) perform in production. Not just deploy and pray that our code will hold strong enough to handle the load. I only see this feature in Scala and Java --not that we wanna compare in this case,

Ops support and transparency is superb on the JVM. That some languages don't even have something remotely comparable is something that didn't even occur to me before expanding my horizon beyond Java.

Yep, the tooling around Java is absolutely fantastic.

Re: Scala vs Go

#33

Post by 100k »

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

Re: Scala vs Go

#34

Post by yummyfajitas »

matt_wulfeck wrote: post #25
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…

That's part of the authors point and one that's I heartily agree with: Go is not necessarily very nice to program in, but other people who have to read and maintain your code find it very nice indeed that you were forced to be frustratingly simple. This was a design choice by engineers who did constant maintenance and reviews no doubt and I appreciate it every day.

I don't find Go simple at all, actually. Any individual line of Go might be simpler than many individual lines of Scala. But understanding how the whole system works can actually get complicated, particularly in code where the lack of generics forces type information to be lost.

Consider a pipeline:

    source ~> retryQueue.firstInput ~> requestAttempter
    requestAttempter.successOutput ~> finalizeResult
    requestAttempter.failureOutput ~> retryQueue.failureInput
This is basically logic to process a stream of messages, successes get finalized, and failures go into a retry queue until they succeed. I've got a large system doing this right now with Akka streams.

In Scala, type signatures ensure that everything lines up or else you've got a compile error. In a similar Go system, I lacked stream abstraction (I think Cloudflare has a beta library that does this now) and the lack of generics mean that streams are untyped.

For example, what if I pass a `Message` object to `retryQueue.failureInput` rather than a `MessageWithRetryMetadata`?

So I don't agree at all that Go code is easier to understand and maintain than Scala.

Re: Scala vs Go

#35

Post by pjmlp »

sly010 wrote: post #31

Does it have to be one or the other? They are suitable for different things. You will find it hard to write an enterprise level application with complex domain logic in Go. Go is low level. Scalas type system on the other hand is very well suited for that. Go's standard library around networking and crypto makes it the best language of choice for pretty much anything network related. Scala doesn't even come close. My…

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.

Re: Scala vs Go

#36

Post by mi100hael »

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

Re: Scala vs Go

#37

Post by sedro »

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

You don't need to specify a return type in scala. In this case the return type is inferred as Option[Long].

You are correct about the exception if the cookie's value can't be parsed as a Long. You might instead write the code as:

  def getUserId()(implicit request: RequestHeader): Option[Long] = {
    request.cookies.get("uid")
      .flatMap(cookie => Try(cookie.value.toLong).toOption)
      .filter(_ > 0)
  }
or, equivalently:

  def getUserId()(implicit request: RequestHeader): Option[Long] = for {
    cookie  0
  } yield value

Re: Scala vs Go

#38

Post by pjmlp »

MrBuddyCasino wrote: post #9
chipz wrote: post #7

One thing that I like about Scala is that we can use Java Mission Control to analyze how our code (to the 'method' level,) perform in production. Not just deploy and pray that our code will hold strong enough to handle the load. I only see this feature in Scala and Java --not that we wanna compare in this case,

Ops support and transparency is superb on the JVM. That some languages don't even have something remotely comparable is something that didn't even occur to me before expanding my horizon beyond Java.

.NET is the only serious rival regarding such tooling.

Re: Scala vs Go

#39

Post by TeeWEE »

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 the JVM, i would chose Kotlin over Scala.

Re: Scala vs Go

#40

Post by mark242 »

ascotan wrote: post #24

I just personally hate seeing a giant method chains in a code block. How do i know how this call chain behaves in production? Where's all the logical exit branches from this for error recovery? Is this properly null checking if required? I see this in python and javascript all the time. This style of programming is what i call 'happy path' programming. It only works properly with valid input. Go forces the developer…

> Is this properly null checking if required?

Yes, because if you're typing the word null in your Scala code you're doing something wrong. Any Java library that might return null should always be wrapped in an Option, so that you're dealing with Some or None, and you never get an NPE.

    Option(myJavaLibraryFactoryMethodUsers()).flatMap(_.sortBy(- _.age).headOption)
...will get you an Option[User] of the oldest user. People who have written Scala for more than six months can immediately recognize what this line of code does, and it eliminates around 20 lines of equivalent Java (or Go?) code. This kind of thing rarely needs to be refactored.
Post reply on HN