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

21–30 of 109 posts

Re: Scala vs Go

#21

Post by agentgt »

ryanslade wrote: post #20
bpyne wrote: post #13

Earlier quoted context omitted.

As I read the author's comparison, OCaml came to my mind as well. Reading Minsky's posts and the Real World OCaml book got me really interested in its capabilities for modern software development. I've heard mixed reviews about the object-oriented features, but the functional ones are solid, expressive, and easy to understand. At home, I started using it as my primary language just a few weeks ago.

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

Re: Scala vs Go

#22

Post by melling »

agentgt wrote: post #3

The language complexity comparison based on the number of pages in the spec is incredibly not useful and disingenuous. The Java specification is actually a fairly good specification and also covers a great deal of the runtime (of which Scala gets a free ride). The C specification is 500 or so pages. IMO the Go specification is sorely lacking in details (albeit I must confess written in a much more modern and pithy wa…

How good is OCaml for web development? I've been considering using OCaml or Haskell for my next weekend project.

I actually used Go for my last one and was happy with it. However, next time I'd like to take a dive into the functional world.

Re: Scala vs Go

#23

Post by ebola1717 »

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.

And that divide is meaningful too. Writing Spark jobs in scala works pretty nicely, thanks to some complicated language features. I have difficulty imagining the equivalent go version being as nice.

Meanwhile, go's simplicity is great for low-level performance-critical code.

Re: Scala vs Go

#24

Post by ascotan »

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 to explore non-happy path cases during development. This leads to java's 'check for null' boilerplate everywhere. The syntax is ugly however, personally believe that it leads to higher quality systems.

Re: Scala vs Go

#25

Post by matt_wulfeck »

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.

Re: Scala vs Go

#26

Post by ebola1717 »

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 carries some baggage from being on the JVM that makes this not-quite-true, but it mostly enforces all of those things in the type system. There's no null-checking required, and if something can fail, the type system should tell you.

e.g. your method signatures will read

doSomethingRisky(): Try[Result]

and to use that value you'll either have to carry that Try forward, or handle its failure cases.

Re: Scala vs Go

#27

Post by agentgt »

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…

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

If this is done correctly this fluent pattern is usually a monad. This works really well with typed languages that have variant types that enforce pattern matching like Scala and Rust.

This pattern is actually far less error prone than imperative null checking (in my experience) as you have to to deal with the wrapped value but it can be equally tedious if the language isn't expressive.

An example of this syntax for Java can be seen in RxJava.

Re: Scala vs Go

#28

Post by voidlogic »

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% of the time embedding does the job of inheritance for my use cases just fine. It also prevents a lot of stupid... (from me and others)

3. "poor dependency management through github links" For all my non-trival projects I always fork all my dependencies into their own repos and then link upstream as upstream. If there is not feature I want or bug that needs fixing, I update them every 6 mo - 1 yr. I do this with every language I use where my dependences are source code and not distributable libraries (.a, .so, .jar etc).

Re: Scala vs Go

#29

Post by alextheparrot »

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?

A lot of Scala is written to be that scaling code, see Spark. I know your point was the possible hand-off between teams, just wanted to indicate it is often used as that scaling language in data-processing.

Re: Scala vs Go

#30

Post by pyrale »

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…

Learn the functional style, and it will look so much more simple.

>Where's all the logical exit branches from this for error recovery?

No exit; the error is carried on in the pipe until the end. Successive transformations simply have no effect, since the data is in error. The chain output type can be either the data you want, or an error.

> Is this properly null checking if required?

Stop using null's.

> This style of programming is what i call 'happy path' programming. It only works properly with valid input.

The unhappy path can be handled just as well, you merely have to incorporate it in the type of output your system can produce. In that way, errors are also a happy path.

> Go forces the developer to explore non-happy path cases during development. [...] The syntax is ugly however, personally believe that it leads to higher quality systems.

When I program in a language like Haskell, not exploring unhappy paths leads to code that doesn't even compile. Usually this leads to pretty good quality.

Post reply on HN