Go Programming Language
Last updated
Was this helpful?
Last updated
Was this helpful?
read
format code according to gofmt, nothing else will be accepted
The Go Programming Language (Addison-Wesley Professional Computing Series) by Alan A. A. Donovan, Brian W. Kernighan
go-internals
Create object as interface type under the OOP concept, which will benefit in the test for mocking out different objects later on.
Avoid frameworks, use libraries if you must, but Go encourages you to write it yourself
go tools and linters, static code analysis - gometalinter, golint, errcheck, golangci-lint itp.
interfaces and mocking them (mockery tool if possible)
avoid global state and init blocks
go encourage to use channels instead of using synchronization
gofmt goimports
"Just do the minimal and keep things decoupled in your same package for easier testing. Keep a close eye on your exported API to make sure it makes sense to others.
The best packages are those that the API is self explanatory. If you flood it with 50 domain objects, 19 aggregates, 40 value objects, 70 specifications, and 5 modules - it is no longer easy to follow.
"Most if not all concepts found in DDD and similar methodologies, guides, patterns and philosophies (SOLID; separation of concerns, the open-closed principle and so forth) are all based in the thoughts of people who spent years and years doing Java and other inheritance-oriented object-models like C++. It's hard to structure such applications well while at the same time keeping enough wiggle-room around to change things later. In that sense this wisdom is priceless and has saved many programmers countless hours of work.
But Go is not like Java or C++, Go is much smaller (C++ has 85 keywords, Java has 50, Go has 25). Also, there is no inheritance and embedding is something that is only rarely used. Add to that the novel approach to implicit interface implementation and you have a language where every package hosts its own dependencies and contracts and has clearly defined boundaries.
Do we need it for Go? We have channels and goroutines.
Go Memory Model
For starter:
More
Cheatsheet
and sample
GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps
and
review comments
dont panic, pro verbs
handle all errors, dont ignore them (use errcheck linter)
package design
struct injection / constructor
goroutines and for loops
and
"I find DDD with Go adds unnecessary complexity, because it tends more to OOP then Go. Go has its own style and trying to port it to Go may not be Go's idiomatic way. However, by keeping "some" of DDD's and general software design principles in mind will be more" - comment from
DDD, while needed in OOO languages, tends to have an adverse effect in Go where things end up being more complicated with object graphs of several structs and aggregates - when you could have just wrote a single func that took parameters and returned an error."
The only conventions/patterns/rules we consider as "good practice" in the Go community is using the basic interfaces that the standard library provides (like io.Reader, io.Writer) whenever possible, instead of inventing new ones that do the same. Some additional common idioms are described in "effective go" ().
After you've written some Go code you'll realize (or get the impression that) "patternism" as I like to call it has gotten out of hand; people doing design-patterns are more concerned with the form of their programs than actually shipping functional code. Hence stuff like the often mocked "ProviderBuilderFactoryFactory". That's why I called that function the antithesis of Go."
go-kit & microservices
clean arch validator
problems with current HTTP Client
go-perfbook
Command line monitoring for goroutines
A tool to list and diagnose Go processes currently running on your system
Why this is important for Java "What is driving the rise of Reactive in Enterprise Java? Well, it’s not (all) just a technology fad — people jumping on the bandwagon with the shiny new toys. The driver is efficient resource utilization, or in other words, spending less money on servers and data centres. The promise of Reactive is that you can do more with less, specifically you can process higher loads with fewer threads. This is where the intersection of Reactive and non-blocking, asynchronous I/O comes to the foreground. For the right problem, the effects are dramatic. For the wrong problem, the effects might go into reverse (you actually make things worse). Also remember, even if you pick the right problem, there is no such thing as a free lunch, and Reactive doesn’t solve the problems for you, it just gives you a toolbox that you can use to implement solutions."
File Watchers