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

51–60 of 109 posts

Re: Scala vs Go

#51

Post by mark242 »

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

It's okay, since cookies is a Map[String, String] so running the get returns an Option[String].

If the author is concerned, the way to express this to be more expressive could be something like this:

    val uidOpt: Option[Long] = request.cookies.get("uid") map {
        case Some(uidStr) if uidStr.toLong > 0 => Some(uidStr.toLong)
        case _ => None
    }

Re: Scala vs Go

#52

Post by MichaelGG »

pweissbrod wrote: post #11

Transportability is an oft under-valued quality when comparing languages. Yes you could write something highly performant/compact/domain-specialized in perl,scala,lisp etc but when the time comes that your product is successful and your team needs to scale or you want to transfer ownership to another team how easy is that transition going to be?

Unless your app is so trivial that syntax and APIs are the dominating factor, I'd wager the team transition will have so much other stuff to deal with. Hopefully, not least of all, the actual program logic.

And team transitions are rather rare compared to the day to day dev that goes on. Optimising for them seems misplaced.

Re: Scala vs Go

#54

Post by dcu »

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

it's funny, this discussion alone kind of proves the author's point

Re: Scala vs Go

#55

Post by kodablah »

TeeWEE wrote: post #42
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 {...}

The ambiguous non-equals form will go away w/ Dotty IIRC. And the presence/absence of parentheses are NOT the same thing.

Re: Scala vs Go

#56

Post by sly010 »

pjmlp wrote: post #35
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.

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 uses akka and apache commons for everything?) yet.

Re: Scala vs Go

#57

Post by pyrale »

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…

You should try Haskell. It's like doing Scala, but without the Java.

Re: Scala vs Go

#58

Post by yummyfajitas »

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…

Scala also forces the developer to explore non-happy path cases. But it does so with meaningful abstractions that don't force you to do it on every single line.

Scala lets you write your code in the style of 'happy path' programming:

    val result: MyError \/ ResultType = for {
        x
Here `g(x)` is a pure function which never has errors. But f(input) and h(y) are impure functions which could return errors.

The error case is handled by `result` being `myError.left[ResultType]`.

To actually access `ResultType`, you use fold:

    result.fold(err => ..., r => success(r))
This makes it pretty hard to ignore the error case.

Re: Scala vs Go

#59

Post by adriaanm »

TeeWEE wrote: post #42
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 {...}

Procedure syntax (the last two lines, lacking the `=`) will be deprecated in Scala 2.13. The two variants before those are due to type inference. Are you really arguing against type inference?

The empty argument list `()` is a convention to denote that a method has a side-effect, whereas a method with no argument list at all is considered pure.

Re: Scala vs Go

#60

Post by mi100hael »

voidlogic wrote: post #28
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…

>Things like the weird split between functions returning errors but occasionally panicking, lack of inheritance, and poor dependency management through github links make Go a poor choice for applications within a business setting. FWIW I've been using Go since 0.8 and this stuff isn't really an issue for me. 1. Panics should not cross package boundaries unless they are meant to be fatal! 2. "lack of inheritance": 90%…

> For all my non-trival projects I always fork all my dependencies into their own repos

That sounds absolutely terrible. Even worse than having to track down & install libraries and headers for C projects. At least in the case of those libraries, you can enforce a particular version using autoconf or whatever. Vendoring source code for dependencies (especially in separate repos) is fragile and a pain for anyone else to track down when jumping in to your existing project.

Post reply on HN