Underscore in globals. Is that really go best practice?
Uber Go Style Guide
61–70 of 140 posts
Re: Uber Go Style Guide
#62Earlier quoted context omitted.
> 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?
I would imagine quite a services to just deal with legislation/taxation stuff in all the different markets they operate in. These can also result on several integrations to government systems - all country specific. In some markets they are partnering with taxi companies - maybe more integrations for ordering and reporting. In general it is easy to underestimate the complexity of systems you are not familiar with. Th…
> In general it is easy to underestimate the complexity of systems you are not familiar with.
Very easy.
A key-value store is theoretically easy, “just store data and give it back”, but a distributed / highly reliable key value store is a crazy beast.
Collision detection and response seems like a “solved” problem but perk at the code and you’ll find just how many lines of code a basic game spends preventing players from waking through walls.
Re: Uber Go Style Guide
#63Why is this better than Google's?
This, to me, seems largely a superset of Google's style guide. There is some specific guidance for working with channels, mutexes, and atomics. My impression from my time at Google was that the Go team really expects you to never use mutexes and atomics, preferring goroutines for all synchronization. Sometimes that is impractical, though.
Re: Uber Go Style Guide
#64I really like the horizontal 'Good/Bad' code comparisons in this guide.
I didn't realize how horizontal vs. vertical code comparison affects readability; IMO horizontal is MUCH more readable.
Example: https://github.com/uber-go/guide/blob/master/style.md#defer-...
Re: Uber Go Style Guide
#65Something that I don't see style guides addressing, but think they should, is how to cancel work when the caller no longer cares about the answer. (Consider an aborted RPC, or someone pressing the "stop" button in their browser.)
A lot of people will do things like:
func (s *Server) HandleFoo(ctx context.Context, in *input) status {
ch func (s *Server) HandleFoo(ctx context.Context, in *input) status {
select {
case ch My impression from digging around the open source world is that nobody except me cares about this. So maybe I'm just crazy. But I really like not leaking goroutines on long-running programs, making Control-C behave gracefully, etc.
Re: Uber Go Style Guide
#66Earlier 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?
When I joined Amazon in 2014, there were ~120,000 microservices. A lot of them arne't used or just hello world tests apps. Every new employee had to spin one up during orientation.
Re: Uber Go Style Guide
#67Earlier quoted context omitted.
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.
Put in English, the type of an unbuffered channel is "a channel that always blocks on writing until the value has been read". The type of a buffered channel is "a channel that doesn't block when written to, until it is full in which case it blocks on writing until some other value has been read by some other unrelated goroutine". The former is a reasonable concurrency primitive. The latter superficially seems similar…
Backpressure to writers is the main reason to use buffer channels IMHO. I have never seen any performance differences between buffered or unbuffered for anything I have used.
The other reason to use them is controlling CPU. Spin up a pool of consumers and control how many cores they use with the buffer.
Re: Uber Go Style Guide
#68I find it amusing that the advice in the style guide gives a good example contradicting another good example, and contains a subtle bug.
In the "Reduce Scope of Variables", second good example leaks an open file when WriteString fails, because it doesn't follow the own advice of "Defer to Clean Up" if you are curious.
(Handling that properly with a defer is a bit more tricky - something like https://play.golang.org/p/l1PeWM3Tisg).
Update: style guide was fixed after this report :) It was this if you wonder: https://github.com/uber-go/guide/blob/a53ee0bef8c0b11b52340d...
Re: Uber Go Style Guide
#69Something that I don't see style guides addressing, but think they should, is how to cancel work when the caller no longer cares about the answer. (Consider an aborted RPC, or someone pressing the "stop" button in their browser.) A lot of people will do things like: func (s *Server) HandleFoo(ctx context.Context, in *input) status { ch This will block on the channel write even if the context becomes cancelled. Instea…
[deleted]
Re: Uber Go Style Guide
#70Earlier 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.
Language fight! Definitely I think that's a good discussion to promote on a thread about _a style guide for a language_!