[achilleasa]

To be fair, I have included a section that extols the benefits of Go modules and hints that this is the way forward.

However, for the book source code, I opted to use dep to make sure it can be used by folks that use older Go compiler versions that lack support for Go modules. That being said, it should be trivial to convert the repo to use Go modules.

[e12e]

> folks that use older Go compiler versions

Why? (I don't mean that as snark; with the ease of installing and upgrading the go compiler compared to the olden days of acquiring a c compiler on a floppy disk - why not target the latest version? I[s] cgo trailing behind?)

[achilleasa]

I'd say it's more of a personal preference really. I have hit some issues trying to use Go modules in the past (although support for Go modules has admittedly improved vastly since the last time I used them) and dep has always worked consistently for me so it seemed like a better choice for the book.

[sswezey]

That seems like a myopic perspective for a book focused on software engineering. The creators of Go see the language as a tool of software engineering e.g. a tool of software development over time. It would be in the best interest of your readers to align with the creators and the community. Teaching people to use an unofficial dependency manager whose usage will only continue to decline in lieu of the official one will do a disservice to your readers and will not age well.

[achilleasa]

I totally get your point but dep was (for quite a bit) the official dependency manager experiment before the proposal for Go modules moved forward and is still hosted under the golang GitHub repo with no deprecation notice. As mentioned in a reply above, the book contains a section about Go modules and makes a case for them being the way forward.