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 <http://doc.akka.io/docs/akka/current/general/supervision.html> 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. Am Samstag, 18. Februar 2017 07:55:37 UTC+1 schrieb 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. > -- 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.
