Factory functions do have their place in Go, however it's wise not to reach for an abstraction before you need it. This typically results in code that has needless indirection, and makes it harder for you, the developer, to read. When writing Go code I like to keep in mind the Go proverb "Clear is better than clever"[1].
From my experience, I've found factory functions in Go to be of use when I'm working with an interface that has multiple implementations and I need an easy way of bootstrapping the interface. Typically using factory functions for simple structs is a pointless thing to do.
Go encourages a closer relationship with the code and the data that flows through your program, this is something that should be embraced.
Factory functions do have their place in Go, however it's wise not to reach for an abstraction before you need it. This typically results in code that has needless indirection, and makes it harder for you, the developer, to read. When writing Go code I like to keep in mind the Go proverb "Clear is better than clever"[1].
From my experience, I've found factory functions in Go to be of use when I'm working with an interface that has multiple implementations and I need an easy way of bootstrapping the interface. Typically using factory functions for simple structs is a pointless thing to do.
Go encourages a closer relationship with the code and the data that flows through your program, this is something that should be embraced.
[1] - go-proverbs.github.io/
This is great advice. Thanks!