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

61–70 of 109 posts

Re: Scala vs Go

#61

Post by pyrale »

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,

Is it available only on Java/Scala, or any language on the JVM ? If Java/Scala, do you have an idea of how much work would be needed to exploit the informations from flight recorder in e.g. Clojure ?

Re: Scala vs Go

#62

Post by kodablah »

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…

I too use Scala and Go professionally and agree with all of your points, but I want to add one. Code reuse. I am tired of copy/pasting, rewriting the same things, forcing my same-lib packages to be unidirectionally dependent, etc.

I've often contemplated what could happen if Go had syntax-extension macros that could build new AST (not go generate, and not in the same language). I believe that Go may in turn become a quality target for a better language. Not oden which didn't have any corporate backing, and from my experiences it doesn't compile fast enough or have quality enough DCE to support reasonable JVM cross compile.

Re: Scala vs Go

#63

Post by kodablah »

mark242 wrote: post #40
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. Pe…

Pedantic since you're just making a point, but maxBy would be the better performing choice though you'd have to do a non-empty check...or just a fold if you can stand a default on empty list.

Re: Scala vs Go

#64

Post by monoid »

I wanted to like the post and then I read this:

> As a developer, the only performance that I care about is my development cycle

Re: Scala vs Go

#65

Post by eweise »

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.

Re: Scala vs Go

#66

Post by pyrale »

dcu wrote: post #53

You can find a similar comparison here: http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala...

I find this article much more interesting than op.

In particular, the focus on keeping functional codebases simple is, I believe, the core of what makes a successful functional codebase.

Basically, at some point when working languages like Haskell, Scala or F#, you are given a choice between power and ease-of-hire/onboarding. Apparently, they made the second choice, which I believe is the good one in their situation.

I believe it is possible to stick to functional languages and make a team-enforced decision to keep things simple, but the choice of simply opting out of it is also on the table, and I won't blame them for it.

I would just have preferred having a simple language AND a great type system.

Re: Scala vs Go

#67

Post by fbunau »

The analysis is done from the perspective of an imperative programmer.

It's like someone writing Java-like Python code. When you write in Scala you completely change the way you write code, the whole paradigm.

This question could be asked Haskell vs Go, it would be the same IMO.

If you have chosen Scala, you don't choose it as a Java replacement, you choose it as a programming philosophy replacement

Edit: Picking on Scala for lack of network libs is like picking on Go for lack of Category theory libs

Re: Scala vs Go

#68

Post by ninly »

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?

Re: Scala vs Go

#69

Post by [deleted] »

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%…

[deleted]

Re: Scala vs Go

#70

Post by Nelkins »

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…

If you're looking for OCaml with a better ecosystem, take a look at F#. It's basically OCaml on .NET.
Post reply on HN