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
On Friday, February 17, 2017 at 10:55:37 PM UTC-8, Will Faught 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?
>
> 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.
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
