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.
On Sun, Feb 19, 2017 at 2:37 AM, Will Faught <will.fau...@gmail.com> wrote: > 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/to > pic/golang-nuts/Fg1I34HrtqU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- Diego Medina Lift/Scala Consultant di...@fmpwizard.com https://blog.fmpwizard.com/ -- 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.
