51–60 of 140 posts
Earlier quoted context omitted.
Probabaly more of an emotional, rather then rational decision. I heard that many Go folks from Google joined Uber. Looking at the stock, they probably should focus on building new things/better the business model, rather then rewriting things in Go.
What else have they got to do, though? Uber have thousands of engineers to develop and maintain a taxi hailing app...
"Copy Slices and Maps at Boundaries. Slices and maps contain pointers to the underlying data so be wary of scenarios when they need to be copied. Keep in mind that users can modify a map or slice you received as an argument if you store a reference to it. Similarly, be wary of user modifications to maps or slices exposing internal state." This could be used as an ad for Rust borrow checker, verbatim. You can't modify…
In reality it's part of a different language which exposes a lot of complexity to the programmer as opposed to Go, which religiously avoids that.
"Copy Slices and Maps at Boundaries. Slices and maps contain pointers to the underlying data so be wary of scenarios when they need to be copied. Keep in mind that users can modify a map or slice you received as an argument if you store a reference to it. Similarly, be wary of user modifications to maps or slices exposing internal state." This could be used as an ad for Rust borrow checker, verbatim. You can't modify…
It could be, if the Rust borrow checker were a Go tool that would solve this problem. In reality it's part of a different language which exposes a lot of complexity to the programmer as opposed to Go, which religiously avoids that.
Earlier quoted context omitted.
It could be, if the Rust borrow checker were a Go tool that would solve this problem. In reality it's part of a different language which exposes a lot of complexity to the programmer as opposed to Go, which religiously avoids that.
No, the point of this observation is that Go exposes this complexity, it just doesn't make it explicit.
No buffered channels, or if you do, you must provide a very strong rationale ;) I still use them quite a bit. Particularly synchronizing large rule sets as bit arrays. Of course you can use sync.Wait instead. But make(chan bool, N) semantics are just more convenient. It's stealth synchronization as a by-product. And hence the warnings about determinism!
I'd like to hear more about this rational. With a single writer, buffering channels can help smooth out inputs when the p90 is much higher than the average with channel writers but not readers. At least that's my impression.
The former is a reasonable concurrency primitive. The latter superficially seems similar, but is actually a much more complicated primitive, with the corresponding code understanding problems and the increased likelihood of more concurrency problems being hidden at low scale but coming out at scale (mostly deadlocks), plus the fact it seems similar is also problematic. The fact that the Go type system does not allow distinguishing between the two is also problematic.
It has some special-case purposes, but I also always scrutinize any channel created with buffering to make sure it is one of those special cases.
Buffered channels have not impressed me with their ability to do any sort of performance improvements. In almost all cases, if you've filled up your readers, you really want your writer to block. It provides cheap, effective backpressure; arguably for software-at-scale it's the most useful aspect of the channel primitive.
The section on exporting functions to check errors just exposes Go's weakness in error checking. It's unnecessarily verbose.
The way to do this properly got much better in the most recent Go release, the linked documentation doesn't yet take that into account, it would seem. https://github.com/golang/go/wiki/ErrorValueFAQ
Earlier quoted context omitted.
Another solution is to use immutable and/or persistent data structures. Of course, because golang doesn't have generics, it becomes unwieldy to have a library of them, unlike what we see in Java, Scala, etc. where these enjoy a wider adoption.
Shared mutable state is evil, so "not mutable" has been proposed as a solution. Rust is different, because Rust's solution is "not sharing". You can still mutate!
Earlier quoted context omitted.
Uber have well over 1,500 microservices written in Go, it is the primary language backend services are written in at Uber.
> Uber have well over 1,500 microservices written in Go 1500 ?! I can't even imagine how micro a microservice could be such that Uber could have so many. edit: Having said that, the Monzo blog post also on the front page says it has 1100 microservices, so I suppose I've just not worked somewhere with 'actual' microservices. What constitutes a 'service', a single procedure for RPC?
These services include all sorts of worker processes, things that manage queues or monitor things, probers, administration, public interface and configuration. It works really well for us.