The article does link to that blog post, and points out some problems with it.
I'm not a fan of this design either personally, in particular requiring a v2 suffix, I think it makes assumptions about versioning which don't withstand scrutiny, e.g. that major versions are always used for major breaking changes. In my experience they are more often used to indicate major feature releases.
I'd really rather go kept the culture of no breaking changes rather than explicitly encouraging them if you move past 1.x.
Looks like there's been a bit of work put in. I especially like how there's multiple sql drivers supported. Instructions on how to add slack were especially nice, I'd been somewhat stuck on the legacy keys (now deprecated).
Hm, at least the handling of interface definitions seems very unidiomatic to me, specifically implementation packages also containing the interface definitions. At least those interfaces are not returned, but structs instead.
Usage of the internal/ package would make sense too. All in all this seems as it would benefit from some go specific patterns.
Options would be nice and i still do not understand the benefit of build tag based config compared to env or flag based approaches.
Indeed, the build tag approach here seems to be just config in code (and thus in version control), switched with compile time flags. Functionally very similar to using a flag when running to do the same thing. ENV or flags for every config option does get quite complex quickly, and you also need defaults so you end up with some config in code and some config passed in (thus keeping state outside the app). I prefer a config file myself, one file per environment, and you can keep them out of version control. Another option is a config service on the private network which apps communicate with to pull configs securely.
On the database side, I simply wouldn't use mongodb, and prefer sql migrations as they're simple and portable. I also prefer using the db for testing where required rather than faking behaviour with mocks.
Agreed interfaces really must be defined at the point of use.
Overall there is far too much abstraction here in pursuit of arbitrary structure borrowed from other people (Bob Martin,12 Factor).
Being boring really is what I love most about Go. It doesn't change much and there is a culture of simplicity, so it's quick to onboard new devs and there isn't a lot to get your head around. That also makes it good for building large projects, as the complexity is in the domain and the application, not clever uses of the language itself.
I almost wish they'd make it more boring and take a few things out, but it's probably too late now to change the language much and people would complain vociferously. Things I never use and wish it didn't have: panic, goto, labels, struct tags, executable comments, even arrays.
The only things I'd like to see improved significantly are enums, errors, and user-space generic collections (coming soon!).
Thanks for posting this, it looks interesting. If you're using # in titles please use it at the end for tags - otherwise things go a bit wonky. I've edited the title for you, and used a tag for your series.
I wonder if it is skewed by larger companies which provide linux workstations, or if some people interpreted the question as which OS is their deployment target? It does seem very high doesn't it? The desktop marketshare of linux is something like 3%, so this answer seems off.
I would imagine the benefit is that it's more dynamic, and could cut down on code size. Wait.. you said "auto generated"? Like you can give a json and have the struct automatically created for it? If that's the case I think I've been doing it wrong this whole time!
I missing functionality from c++ google mock library where running generator wasn't required. In go I see a lot of custom written assertion and in most of the big project mocks are self written. I would be nice in the future see support for assertion or mocks in go standard library.