[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.