Ask HN: Should I learn Scala or Go? | Hacker News Reader

Ask HN: Should I learn Scala or Go?

13 pointsmangeletti32 comments

I understand they're from two different paradigms, and I'm interested in learning both to some degree, but I would like to heavily commit to mastering one.

I'm a Python developer. This is probably at least 1 + vote for Go, since there are quite a few Python developers that have learned Go and a lot of articles have been written specifically for people like me. Scala, on the other hand, tends to be similarly popular among the Java community (Scala runs on JVM, etc.). I'm ignoring this fact for the time being, and I'm ignoring the difficulty of learning each language for this exercise. I'm primarily interested in thoughts on:

1. the languages' communities as a whole

2. the languages' qualities/problems (be subjective - this is not StackOverflow)

3. the possibilities of personal economic gain from learning each (e.g., where/why do you think your choice will grow, etc.)

View on HN

Golang if you're writing systems-y network-y code more than application-y database-y code.

Scala if you're more interested in language theory and statically analyzable correctness. Or, again, if you're doing anything database-intensive.

Golang is a very pleasant language to get systems-y things done in. I'm fond of saying that it's not an amazing language, but is an amazing programming tool.

Scala is going to be much friendlier to you if you're into language features; generics would be a big one, pattern matching is a Scala-y one.

Are you writing web apps? I'd give the nod to Scala.

Are you much more inclined to write a web service, something that spits JSON out instead of HTML? Golang back in the running.

IRC server? Golang.

Social network? Scala.

Emulator? Golang.

Compiler? Scala.

Do you like C, even though you never use it anymore? Golang.

Do you think a lot about someday learning Haskell? Scala.

Are you picky about languages? Golang will occasionally frustrate you with the things it lacks. Scala will occasionally frustrate you with the things it has.

They're both good languages and --- unless you need a graphical UI (in which case: Scala) --- both of them will do better than Python for almost any task.

Excellent, thanks for the breakdown.

I'd just like to point out that most of our customers have webapps written in go - not just JSON apis so this argument that go is not for webapps is at best incorrect. I talk to gophers around the world everyday that are using it just for that.

They much rather hack on a webserver that they can use in 15 LOC from stdlib than some beefy JVM framework.

From the conversations I've had I strongly believe most webapps are going to be written in go in the coming years.

I'm a full-time Golang developer, the last product I shipped was a Rails app, and my career started in the 90s as a shrink-wrap C software developer. Golang is an unpleasant environment in which to build web applications:

* Good SQL persistence abstractions aren't there yet, so realistic SQL-backed applications depend on writing tons of raw SQL and (worse) parsing results. Like a savage.

* Golang's built-in templating is good for self-contained full templates but not great for hierarchies of templates and partials.

* Golang's net/http library is so good that it's a gravity well for other request handling abstractions, so that sessions, CSRF tokens, and access control either have to be built directly on Golang's equivalent of Rack, or inevitably get put into libraries that conceal too much of net/http.

"Going with the flow" and writing idiomatic Golang code feels a lot like writing those Sinatra apps where you get 1/3rd of the way through and regret not just using Rails.

You can totally write a good web app in Golang, especially if you're doing minimal serverside HTML generation and leaning on something like React or Angular or Ember instead. But it's not what Golang is best at.

Meanwhile, Scala is both a language designed in part for serverside web apps and built on the JVM.

If you're writing a web application, where your functionality is exposed by a port 443 that Firefox connects to directly and asks for "/" from, I'd prefer Scala to Golang.

Reasonable people can disagree or object to any of this, but I'm not going to waste time sugarcoating.

Thanks. This is really helpful advice, and the ORM-related comments you made resonate with me, because the use of abstracted data backing services is sort of the meat and potatoes in just about any web app I can think of, and this was a real pain point in my initial research of Go. All of the ORM-ish things I've found are mediocre, at best, IMHO.

I ROFL at "Like a savage.", btw.

You can get around it by using more recent databases; Rethink for instance might close the gap. But then you're using an idiosyncratic database for kind of a weird reason. Personally, I want to preserve a default of using Postgres, and I don't like that Golang pulls me away from that a little.

That said: I really like Golang a lot.

For Microcorruption, we did the overwhelming majority in Golang, exposing it as a JSON RPC endpoint, and then did the UI in a very small amount of Rails. It worked quite well.

One thing you can for sure say about Golang: it is fast. We deployed 3 app servers but if we had deployed only 1 it still wouldn't have broken a sweat.

I agree 100% about your Postgres point. I don't want to ever be in a situation where I can't use Postgres, unless we're in a situation wherein Postgres has taken the back seat to some other database that is A) ACID compliant, B) really fast and scalable and B) fairly widely adopted.

Agreed: 1) SQL is not solved in an ORM sense. Yes you will have to write sql statements. I'm not so sure this is a bad thing.

Beg-to-differ: 1) Templating works very well for me. You can pass variables to embedded template "partials" within a template. You can define your own functions for the templating engine to use etc. 2) net/http + gorilla (or something similar) and you have all of net/http exposed with some sugar on top. 3) csrf tokens are just a simple library. Yes you do have to be sure to put them into your templates.

If you are having difficulty with a middle-ware concept in terms of golang there are plenty of resources online.

So I would say that I have a different feeling about making websites in golang :) I enjoy it.

Those are a lot of the same things a Sinatra programmer could have said about using Sinatra instead of Rails. And it's true, you can, and in some cases you might even enjoy it (if nothing else, the code is more transparent in Sinatra or Golang).

If, however, you've had the experience of starting a project in Sinatra and ruefully finishing it in Rails, my advice is: don't do full-featured web apps entirely in Golang.

> I'd just like to point out that most of our customers have webapps written in go - not just JSON apis so this argument that go is not for webapps is at best incorrect.

The fact that your customers are using Go for webapps does not mean that tptacek's statement that he would give the nod to Scala for webapps but consider Go in the running with Scala for web APIs. Advice is not "incorrect" because some people make different choices.

> From the conversations I've had I strongly believe most webapps are going to be written in go in the coming years.

I'll be surprised if that ever happens. There's plenty of languages that have a good story for webapps -- Go certainly isn't the worst choice, but the advantages it has over some alternatives aren't all that unique, nor are they without tradeoffs. I wouldn't be surprised to see Go continue to make gains for a while (and then be passed up by newer things), but I don't see it ever being most webapps.

You state for web services that spit out JSON that Golang is better. Typically the JSON is a representation of data from a database (relational or otherwise) - how do you envision Golang doing this (spitting out JSON) well?

From a cursory look at Golang, I think there is a serious possibility to displace a lot of enterprise Java stuff especially web services that process XML at scale. There is so much baggage and stacks of frameworks to contend with that something much closer to the bare metal, so to speak, would be refreshing to use in that space. But if the DB handling is lacking that could be a turn-off for displacement.

You still have the persistence problem, but you don't have the others, so it's less of a drag.

I would bet money a network server in Scala can run circles around Go.

1. Both communities are big enough, if you are in Asia, gophers are everywhere

3. If you don't have any knowledge about functional programming, Scala will open you a new world. It will force you to think in a different way and will introduce you to many new concepts in how to solve parallelism and asynchronous computation using easy concepts like immutability or far more complex like functional reactive programming or duality.

2. I worked with both languages, I liked the fact I was able to write a whole, easy, REST web app in just half a day with Go, but the syntax and the verbosity in error handling, made me kind of crazy. I would definitely say that is a very good language, extremely fast compared to others like Ruby or Python and it can be even a very good complement to Scala.

Scala is my favorite language, by far, for server side projects. It requires time to be mastered, there's never a "Scala way" or a single way to solve a problem, but there's (almost) always a best solution. Twitter's scala school[1], for example, is a good place to see examples about when and how to use certain language features. The fact that runs in the JVM, a Virtual Machine with 20 years of development, improvements and optimizations, is almost a killer reason to pick Scala. I worked with Java/Spring/Hibernate in the past, a very frustrating experience, but Scala changed my mind about the JVM and opened a completely new world: Functional Programming. Now I know and use concepts like Monoids, Monads, Future/Promises, Reactive Programming, Actor Model, Duality, etc... without any problem. It's a complete different world and I think it deserves a shot.

[1] https://twitter.github.io/scala_school/

For background, my last few years experience were in Scala and I'm now writing golang systems.

Item 1:

Both golang and scala communities are large enough now that you aren't dealing with lack of community as an issue. There are very bright people working in both communities and there is a lot of passion for the languages. Unlike something like Java or Php, if you are working in one of those languages it is largely because you want to be. That said, I'd say both communities suffer from an abundance of arrogance that is above normal for other languages.

Item 2: You can learn go in a couple of hours. Its warts are obvious on casual inspection and typically if you aren't doing something the "go way" you will pay for it. This usually isn't a practical problem but occasionally the "go way" leaves you stuck.

It took me a solid year to learn Scala to the point I would call myself competent. I still have zero degree of confidence in dropping into an existing Scala project for the first time. Part of that is a design decision as there is "no" Scala way. Part of that is the community itself has a large contingent of language tinkerers who will try out experimental features. But I've never seen a problem that couldn't be solved in a Scala code base in an "elegant" way. Incomprehensible is also easier in Scala.

Item 3: I doubt there is any way to predict this and it is largely not the way I would choose a language.

Personally, golang the language irritates me like crazy. I do like the simplicity for small web services or cli tools though. If something starts approaching the "bash is too much" here, I happily do a quick golang program. This is more a function of the go tool chain than anything else, but if golang has proven anything, its that the tool chain matters.

Conversely, I doubt I will ever write a system again in Scala. I'm glad I did, and learning Scala made me hone some development chops I wouldn't have otherwise, but it isn't something I love programming in (even though it doesn't irritate me like golang does).

My advice would be to learn Scala, but that is largely because I think paradigm shifts are more long term rewarding than language/framework shifts. Golang hasn't taught me anything I didn't already know and if you do need to learn it for a job or something it isn't hard to do.

Scala is syntactically complex, compiles relatively slowly, and some of the tools (IDE plugins) are terrible. Or, at least, they were a few years ago. On the positive side, you'll have a more mature ecosystem of third-party libraries since you'll be able to tap into everything Java offers.

Go, on the other hand, has a simple syntax, excellent tools, and compiles lightning fast. Depending on what you're doing you may not have the library support you need.

Thanks for the reply and the data about each. Compile time is actually something I hadn't given one iota of thought about, likely because I've never really worked in a compiled language. I imagine this is a huge pain when you want to make a quick production change or you just like to get quick changeset feedback.

c++ had huge compile-time issues which is one of the motivations behind go's compile-time speed - it feels like you are working in a dynamic language

It is largely not a problem for that because Scala's incremental compiles are reasonable and test time dominates build times in either case.

The speed of the go tool chain becomes a huge asset when it comes to integrating with other tools. This allows freedom to use the environment you as a developer want to use. Being able to work exclusively in vim/tmux after years of needing intellij to be productive is a breath of fresh air.

Compilation is speedy enough that you can just use `go run` in development and it feels like running a python script.

If you can afford the JVM (hardware wise and startup time wise), I think Scala wins hands down.

Now, people will say "Scala will be better for it's type system and correctness, and Go will be better for performance/network applications". But they'd be wrong.

You can check out here:

https://www.techempower.com/benchmarks/

If you compare scala (scalatra in this instance) vs. Go for multiple queries, you can see Scala's more performant than Go. Part of this is because the Go GC is still new, while the JVM has had a lot of time to tweak things. For network apps, Scala plays quite nice with Netty, which is the JVM's non blocking asynchronous network framework.

So, I think you should learn scala if you want to stick with server side code. However, some reasons you may not want to pick scala:

1. You'll be more productive quicker with Go. I think C# folks can be productive with Scala right away, but from python it will take you some learning.

2. Tooling. Scala's tooling is sub par compared to some other languages, so there's definitely a period of learning the language where you don't know enough to get a productivity gain, but the tools can still frustrate you.

3. JVM startup time. I imagine Go is always the better choice for anything client side.

http://rosetta.alhur.es/compare/scala/go/#

I find that the Go and Scala versions for most of those examples both take the same amount of time to read.

This isn't an accurate depiction of what scala ends up looking like.

If all scala stuck to simple idioms like in the example, it'd be an excellent language.

Learning Scala in a significant sense of learning, means also learning the JVM, SBT, and some degree of Java because "That's stack, Jack." Scala errors sometimes talk in terms of Java and having a mental model of Java helps a programmer parse them (it's like Clojure in this way).

I don't see either as high market share among general purpose languages. There are almost certainly more jobs in Python than both combined.

(throwaaway here)

Before you waste the next few months of your life learning a corrupt programming language:

- Typesafe co-founder quits: https://www.youtube.com/watch?v=uiJycy6dFSQ - https://vimeo.com/64716826: Paul Dix - Why Node and Scala will dry up: Go will drink their milkshake

- I can personally tell you, scala is awful at handling large codebases and is so filled with idioms, you have a difficult time reading it. I remember opening scala code, seeing english, but it felt impossible to decipher.

- You feel clever when you write it. No doubt about that. Other programmers and your customers don't care.

- Compilation time: It's atrocious, we're talking 1 to 10 minutes to compile web apps.

- Package dependencies: You end up incorporating java at the end of the day. Version mismatches.

- As for the "functional language" thing, just pick real Haskell or Ocaml. Don't fall prey to scala being a functional language.

- You need to rely on a huge, laggy IDE with missing / out of date plugin packages to get autocompletion.

On the other hand, Golang:

- compiles these massive applications in line 2 seconds.

- It's highly lintable.

- The syntax is just... dumb.

- Yet you don't feel limited at all.

- It runs fast-fast-fast without having to rely on JVM.

- Familiar syntax... like a hybrid between Python and C

- You can import packages from github / git repos, automatically grab dependencies with one command.

- The build system and tooling is simple and genius

- Autocompletion (https://github.com/nsf/gocode)

OP: I hope you don't waste your time on a scala venture. Scala has it's die hard fanboys, especially those who spent 15 years in java and have too much of an ego-investment to think anything else, but even the co-founder of typesafe, the most prolific committer says the language is a mess.

> the most prolific committer says the language is a mess

This is a lie. He says the compiler implementation is a mess. he's still a contributor and involved in the language.

Second, your argument is basically you aren't smart enough to write/read scala. I love it. I have more faith in the OP.

Not everyone needs idiotic languages that ignore 30 years of programming research to coddle their fragile ego. We're not all like you.

  He says the compiler implementation is a mess. he's still a contributor and involved in the language.

The implementation is a mess because the specification permits so much grammar and syntactic idioms. The moving target and bloated spec is worsened by package version, language mismatches and incomplete repositories.

Of course your compiler is going to be an unmaintainable jungle when you treat the language itself the way most others leave for standard library or even separate projects.

Golang does the opposite, and lives in splendor. Compilation times are imperceptible. Syntax is simple. Standard libraries are solid. Third-party projects are importable via git repositories. Golang is about keeping it tight, staying out of your way, helping you where it counts most, and trying to minimize the downsides.

  Not everyone needs idiotic languages that ignore 30 years of programming research to coddle their fragile ego. We're not all like you.

Golang is written by Rob Pike. Both languages build upon a legacy and have their pragmatic elements.

  Second, your argument is basically you aren't smart enough to write/read scala.

The job is to ship features. Clever code and arithmetic bring little value.

I'm happy to see that Java programmers can have a cleaner language and some nice functional features. I wish they'd spec things out with more forethought and reigned in the idioms.

You fail to understand that you cannot extrapolate simplicity in the small to simplicity in the large. It's a common mistake people make, but the sooner you realize it the better you'll be as a programmer. Go is simpler than Scala. Scala has more warts than Go. But Scala is more powerful than Go.

If I write a sort algorithm, I'm going to have to reimplement that x number of times for each custom collection I write. You think this makes for a simple app? No. It makes for a convoluted mess. You can have a lot of features in a language and rely less on custom frameworks and duplicated bloated code, or you can prefer the inverse.

Are you familiar with the advantages of parametric polymoprhism? If you think the job is to ship features that work, you should google this, along with theorems for free.

  Are you familiar with the advantages of parametric polymoprhism?

What problem does it solve? How does it help give my startup more runway? How does this impact my bottom line?

Scala

Thanks for the reply. Would you mind explaining why you choose Scala?

Reply on news.ycombinator.com