Uber Go Style Guide
github.com
Uber Go Style Guide
1–10 of 140 posts
Re: Uber Go Style Guide
#2Is Go the primary language in Uber now? I see a lot of tools written in Go coming out of Uber. What kind of services inside Uber is Go used for?
Re: Uber Go Style Guide
#3Is Go the primary language in Uber now? I see a lot of tools written in Go coming out of Uber. What kind of services inside Uber is Go used for?
Uber's distributed time series database M3 (https://m3db.io) is written in Go.
Re: Uber Go Style Guide
#4"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 a map or slice you passed as an argument if a reference to it is stored!
Re: Uber Go Style Guide
#5Correct me if I'm wrong, but, isn't the primary purpose of `gofmt` to solve having to deal with style guides like these in the community?
Re: Uber Go Style Guide
#6"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…
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.
Re: Uber Go Style Guide
#7Correct me if I'm wrong, but, isn't the primary purpose of `gofmt` to solve having to deal with style guides like these in the community?
This is referenced in the first paragraph of the style guide:
"Styles are the conventions that govern our code. The term style is a bit of a misnomer, since these conventions cover far more than just source file formatting—gofmt handles that for us."
Re: Uber Go Style Guide
#8"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…
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!
Re: Uber Go Style Guide
#9Is Go the primary language in Uber now? I see a lot of tools written in Go coming out of Uber. What kind of services inside Uber is Go used for?
Yes, Go is the primary language in Uber.
Re: Uber Go Style Guide
#10Pretty good. Some opinions that fall under "be consistent within our code base" (which is why Uber should have a style guide at all), so all good.
Just one comment though:
> Embedding sync.Mutex
Never do this on an exported type. If you embed sync.Mutex that makes "Lock" and "Unlock" part of your exported interface. Now the caller of your API doesn't know if they are supposed to call Lock/Unlock, or if this is a pure internal implementation detail.
your `type Stats` "isn't" a mutex. It has a mutex.