3 ms·
That's part of the authors point and one that's I heartily agree with: Go is not necessarily very nice to program in, but other people who have to read and main
by matt_wulfeck 10y ago
That's part of the authors point and one that's I heartily agree with: Go is not necessarily very nice to program in, but other people who have to read and maintain your code find it very nice indeed that you were forced to be frustratingly simple. This was a design choice by engineers who did constant maintenance and reviews no doubt and I appreciate it every day.
- yummyfajitas 10y agoI don't find Go simple at all, actually. Any individual line of Go might be simpler than many individual lines of Scala. But understanding how the whole system works can actually get complicated, particularly in code where the lack of generics forces type information to be lost. Consider a pipeline: source ~> retryQueue.firstInput ~> requestAttempter requestAttempter.successOutput ~> finalizeResult requestAttempter.failureOutput ~> retryQueue.failureInput This is basically logic to process a stream of messages, successes get finalized, and failures go into a retry queue until they succeed. I've got a large system doing this right now with Akka streams. In Scala, type signatures ensure that everything lines up or else you've got a compile error. In a similar Go system, I lacked stream abstraction (I think Cloudflare has a beta library that does this now) and the lack of generics mean that streams are untyped. For example, what if I pass a `Message` object to `retryQueue.failureInput` rather than a `MessageWithRetryMetadata`? So I don't agree at all that Go code is easier to understand and maintain than Scala.