I am looking at examples of real world professional usage for somebody already familiar with the language constructs and syntax.
Also, I would advise actively avoiding the big names you have heard of. A lot of products are successful despite having garbage code. And even more of them are successful despite having only decent code, full of stuff not worth emulating.
Try to identify people who have a lot of experience and a strong command of the language, then look at their most recent projects.
https://medium.com/@matryer/how-i-write-go-http-services-aft...
The book might be good, but my copy had a problem with spurious characters in every code block, but that seems to be fixed in later printings.
Is there a particular piece of code (as in, a single package/file/function) that jumps out to you as "gorgeous?" When I look at a random Hashicorp repo, it strikes me an impenetrable labyrinth.
Fairly idiomatic/clean
As a golang beginner, the go stdlib is one the most readable stdlibs I've read through. The combination of gofmt, manageable language features, and idiomatic ways to do things make most go code fairly easy to read.
I know go doesn't have a million language features, but readability after the fact is one of the benefits of this approach.
There is much better code to read. I second the recommendation of HashiCorp's stuff. Stay away from Docker and especially Kubernetes.
But some of Go's language decisions only become clear once you've written a lot of Go
For example, the "var name = expr" declaration form seems unnecessary in light of the short ":=" form but it is in the language to allow indented declaration blocks like this (where some variables get an initial value and some get just a type):
var (
text []byte
last int
more = true
)
...
Another great read for learning go that covers the more traditional challenges of standing up a basic web service with user accounts, testing, metrics, etc. is https://github.com/benbjohnson/wtf and the accompanying blog posts that cover how to structure such an application and why.
I think the source code for pkg.go.dev is actually a treasure trove of good ideas and design patterns, especially if you are trying to make a small to mdedium sized web app (which, lets be real, is almost all web apps anyone will ever make). https://github.com/golang/pkgsite
Please avoid: Kubernetes, AWS code.
As a rule of thumb - less imports is better.
There are a few disturbing things:
1) Usage of `utils` package. Points against it were made in:
https://dave.cheney.net/2019/01/08/avoid-package-names-like-...
https://github.com/golang/go/wiki/CodeReviewComments#package...
2) Check out the number of dependencies. This looks almost like NPM hell.
3) Lack of standardization and consistency. This project is so big, and there are so many contributors with their coding styles that the project looks untidy.
4) A lot of import renaming is a symptom of package name clashing or simply poor package naming. You usually do not need to rename import, and this is simply not required if your package structure was carefully thought about.
Again, k8s is great. K8s solves a lot of problems. I love it, but it is not a great example of Go code.
Basically they've reinvented the wheel a bunch of times and now it's too late to import stdlib.Wheel =)
Half of the point of Kube is that every object looks similar enough that you can deal with them generically. ObjectMeta is what enforces that, so yes it’s OO, if there was only one base class possible and no inheritance. The ObjectMeta as an interface construct exists for performance reasons in Kube vs the reflection we used early on (which was mostly due to people learning Go and dealing with limitations of the language as we rapidly prototyped new ways of building out our object patterns).
A prototype of kube was done at google in Java, none of that survived translation to the open source project (edit: or was rewritten prior to v1 as we matured the subsystems that replaced the basic concepts in the day 1 project, like clients writing directly to etcd). Many of the early authors had lots of Java experience, but there was never any attempt to bring Javaisms into Kube or any Java to be converted, just conventions.
EDIT: actually, metadata/spec/status is more a repudiation of Rails and the active record style “hundreds of properties with no organization” JSON apis. We wanted to clearly separate metadata (common), spec (desired intent), and status (actual state). That led naturally in go to an embedded struct for ObjectMeta and then the interface for getting access to the generic properties on any object.
My comment was based on watching this talk: https://archive.fosdem.org/2019/schedule/event/kubernetesclu.... Kris Nova quotes Joe Beda saying they "rewrote Brendan's prototype (in Java), to go". And then goes on to discuss how this led to many of the patterns in Kubernetes.
I agree with the other commenters that stdlib is excellent for delving deep into the language.
I've been intending to look up Golang on the site but I forgot until now. Thanks!
They are the The world’s most advanced native GraphQL database with a graph backend.
Checkout their GitHub repo.
https://github.com/mattermost/mattermost-server
And I disagree with those that say stdlib is the best way of looking at the best Go code for two reasons:
1. A lot of times stdlib code is restricted to use only backward compatible code with old API contracts, some parts are neat but others are unwieldy. It's a hit or miss.
2. Library code is different to application code. You can't get as much variety in style, abstractions, design patterns in stdlib as you can in a real world application.
I reckon it's important to read to get a whiff of succinct Go code, very good at learning protocols (like OAuth, Http etc) if you're interested, but won't be hugely helpful in building a CRUD app.
https://pkg.go.dev/github.com/mattermost/mattermost-server/a...
This is atrocious stuff.
This is my result:
To see examples of good source code just click thru the function names when searching the documentation. E.g. https://golang.org/pkg/net/http/#NewRequest They link directly to the source code, and the standard library is extremely well commented.