Re "go new": I think part of the problem with that is that people have quite different ideas of what a good project structure is. It also varies a lot between a simple CLI tool (for which main.go and maybe go.mod is enough) and a large multi-package server project.

Can you explain what you mean by "bizarre Makefiles"? I've never used Makefiles for my (admittedly fairly small) Go projects, because "go build" just works.

I've seen a number of projects where the root directory is a load of other folders and then there's a Makefile and it's a kafkaesque nightmare.

I agree on the toplevel `main.go` vs the `./cmd/myapp/main.go` style needing catering for that only comes out as the project evolves... maybe it should be a go vet addition instead :D

Go modules are removing the need for much of the Makefile magic. You still have use of a Makefile if you need vendoring or are dealing with non-public branches, but things can be much simpler.

I'm the author of that presentation, and I'm surprised to see the very similar content and structure, to say the least. I left a comment on the Reddit thread[0] to see if I'm missing something.

[0] https://www.reddit.com/r/golang/comments/ginp22/whats_coming...

Thanks -- I replied in full there. I reused your title, which I can see was confusing. However, this is all my own writing and research, primarily from the official (draft) release notes, new linker design doc, golang-dev, and GitHub issues. But your slides were a minor source, so I still should have attributed them. That would have helped you and not hurt anyone -- sorry!