Arguments for writing fast, high-load servers in Go instead of Scala?

[Will Faught]

I want to make the case to a software architect where I work that we should write some fast, high-load servers we need in Go rather than Scala. What pragmatic arguments should I use?

Note that the architect isn't against ever using Go; the question is whether to use Go now, for these servers in particular. Not much detail has been hashed out yet about them, aside from general speed and load requirements.

As a general example of a pragmatic reason one might choose Go over Scala, the architect said Scala would be bad for making a standalone program that checks gRPC health endpoints because the binary would be large and the start-up time would be long.

[Henrik Johansson]

The cognitive difference is huge in Go's favor. Aside from that the new impressive gc results built for low latency can be a good argument.

We have deployed a number of services in Go over the past months and are very happy with the performance. We used to do all these in Java but Go is easier to both develop and deploy as well as fast so the choice is easy going forward.

The only argument imho could be if you have some library in Scala/Java that implements something really specific with high quality then it makes sense I guess to reuse that.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Diego Medina]

The reasons we have for moving our Scala heavy process app to Go are:

1. Much, much smaller memory footprint, both, initial app running and then loading the same number of items from our database.

2. During development, compilation time.

3. Version upgrades:

    As long as you vendor your Go dependencies, you are golden (and by this point, unless you write libraries, you should be vendoring), Go 1.8 just came out, I didn't have to wait for my 5 dependencies to publish a Go 1.8 compatible version. Every time Scala comes up with a new version, I do have to wait for all my deps to be built for the new Scala version (And as a library maintainer of a large Scala web framework, have to deal with updating our code/publishing/etc)

4. This may or may not be a big point for your architect, depending on his/her preference, deploying a Scala app just takes longer than a Go app. (jar size with all dependencies vs a Go binary)

That being said, I try to control risk when introducing a new tech at work, I hope this won't be your first Go app. I personally wrote several apps on the side before we started using Go at work, because I didn't want to run into cases where I made s silly mistake and then the rest of the team would use that to say Go is terrible, when in fact it was just me making a mistake/misusing a feature, etc.

Hope that helps.

Diego

[Will Faught]

Definitely not my first rodeo. :) Been using Go professionally for a couple years. I've done a lot of Java stuff in the past, and I suspect Scala/JVM work will be as burdensome.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Fg1I34HrtqU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Diego Medina]

On Saturday, February 18, 2017 at 10:29:03 PM UTC-5, Will Faught wrote:

Definitely not my first rodeo. :) Been using Go professionally for a couple years. I've done a lot of Java stuff in the past, and I suspect Scala/JVM work will be as burdensome.

Great! hope you and your team get to use Go on this next project.

[Will Faught]

Thanks to the two replies so far! Very helpful.

Here are the reasons I'd thought of before sending the question. I don't know Scala, so maybe some of these aren't advantages relative to Scala in particular; if so, please let me know. Ideas and feedback are much appreciated!

# Concurrency and parallelism

- Simple, well-defined concurrency memory model

    - Happens-before guarantees for channel sending and receiving

    - Lock and atomic primitives

    - Built-in build/test data race detector

    - Goroutines (lightweight/green threads)

    - Part of the language

    - Small and fast (4 KB in memory, no context switching)

    - Multiplexed onto all processor cores for automatic parallelism

- Channels

    - Part of the language

    - Simple send/receive/close semantics

    - Concurrent sends and receives are safe

    - Buffered and unbuffered

    - Send any type, even other channels

    - Enable concurrent composition of components (think pipelines, fan out/in)

- Orchestration

    - Built-in support for orchestrating concurrent work

    - Work deadlines, timeouts, and cancellations that can span APIs and processes

    - Concurrent code looks synchronous

    - No callbacks, promises, or futures

- Performance

    - Fast, native, statically-linked builds

    - Small disk and memory footprints (basic server: 11 MB on disk and 2.3 MB in memory)

    - GC pauses are usually under 100 microseconds and often as low as 10 microseconds

    - GC tuning unnecessary and GC performance scales with memory size automatically

    - Hundreds of thousands of goroutines per process is practical

    - All tests can run in parallel

    - Regexps are guaranteed to run in time linear to the size of the input

# Tooling

- Easy development: quick and simple to clone repos and then build, test, and run code

- Single command-line tool that does everything

- Built-in testing, benchmarking, profiling, package managing, documentation, coverage

- Code buildable from source alone; no third-party build tool (make, ant) needed

- Fast builds (object files are cached; only changed code is rebuilt)

- Cross compilation for various operating system and architectures

- Deploying an executable is just copying a single file

- Thorough, official language spec and standard library documentation

- Modern standard library with built-in transport clients/servers and encoders/decoders

- Simple build tag logic with file name suffixes and file comments

- Built-in dependency vendoring

- Built-in code formatter and linter

- Built-in code generation

- Clean builds (no warnings or logs; successful builds print nothing; no build artifacts)

# Design

- Uses interface composition, not class inheritance; avoids complex type hierarchies

- Built-in equality/comparisons and hashing

- Simple package model for encapsulation and distribution/use

- Unit tests for service interfaces can double as integration tests

[Diego Medina]

Looks like you have a pretty good list already, depending on how much they love Scala, they may/may not invalidate some of your points but you know them better.

--

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Fg1I34HrtqU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

[Haddock]

I would say that CSP in Go using channels and goroutines make concurrent programming a lot easier than with actors in Scala (Akka). Reason is that it is easier to detect races and deadlocks in Go at development time (code using CSP easier to understand than code using asynchronous calls) and at runtime (again, asynchronous calls are the problem and actors in Akka make life easier but do not address the issue at a fundamental level as CSP).

One advantage of Scala/Akka is distributed programming. The concept of supervision in Akka makes distributed programming much more reliable. IMHO, Go is lacking as what distributed programming is concerned, e.g. there is nothing with the safety of supervision in NATS and other Go libraries for distributed programming. But if you don't need distributed programming, Go may just be fine.

[Konstantin Khomoutov]

On Fri, 17 Feb 2017 22:55:37 -0800 (PST)
Will Faught <will....@gmail.com> wrote:

> I want to make the case to a software architect where I work that we
> should write some fast, high-load servers we need in Go rather than
> Scala. What pragmatic arguments should I use?

I do not do Scala but since I'm trying to keep tabs on what happens in
my industry so I'm used to read success/failure stories when I happen to
come across one. I find [1] to be of interest to your case, and it
refers to [2] which is an in-depth report of someone made huge use of
Scala and finally decided to move to plain Java.

The post is kind of old but I'm not sure the situation could have
changed drastically during a single year.

1. http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/
2. http://codahale.com/downloads/email-to-donald.txt

[Kevin Powick]

You may have come across this already, but here is another example of a team moving from Scala to Go

https://movio.co/blog/migrate-Scala-to-Go/

Though not a move from Scala, Uber has also published some articles on how they've built high-speed services with Go.

https://eng.uber.com/go-geofence/

--

Kevin Powick