大家好，我是煎鱼。
不知道大家平时在日常工作中，会不会遇到一个问题？公司用着微服务架构，经常要创建新的服务，需要一个应用模板去初始化新的服务，减少 ctrl+c+v，转为相对自动化。
不同团队根据 Leader 的喜好、要求不同，应用模板又会不同。有的喜欢 DDD、有的喜欢 MVC、有的大道至简即可。每家公司都会延伸出一个工具链做这个事情。
新工具：gonew 生成模板
在 Go 社区也出现了这种诉求，Go 核心团队带头大哥 @Russ Cox 发起了一个新讨论《gonew: templates for new modules[1]》，引发了各方的热议：
图片
原因是：Go 团队经常收到用户反馈要求使用某种 "go new" 功能，以某种基本模板启动一个新的模块（项目）。
这个工具不局限于 Go 团队提供的模板，任何人都可以定义这个模板。这个模板也是很 “普通”，没什么特殊的功能。
"go new" 的核心工作是下载一个模板，更改其模块路径，然后把它放到一个新的目录中进行编辑。当然这个工具链未来可能还有更多的功能，但这就是最核心的诉求。
也出现了一个新的场景。有一名图书作者，希望能够更方便的提供图书示例，不想要图书读者费尽心思克隆一个 git 仓库。答案显而易见，那就是本文提到的 gonew 工具。
快速体验和实操
结合前后事迹来看，@Russ Cox 是一个执行效率比较高的人。提出讨论的前几个月，已经写好了工具给大家试用了。
安装命令如下：
$ go install golang.org/x/tools/cmd/gonew@latest
go: downloading golang.org/x/tools v0.11.1
go: downloading golang.org/x/mod v0.12.0创建命令如下：
$ gonew golang.org/x/example/hello
gonew: initialized golang.org/x/example/hello in ./hello执行完毕后，会在当前目录下，创建一个 hello 目录（./hello）。模板的结构如下：
$ tree hello
hello
├── LICENSE
├── go.mod
├── hello.go
└── reverse
├── example_test.go
├── reverse.go
└── reverse_test.go
1 directory, 6 files我对比了一下，和模板基准的 git 仓库 github.com/golang/example 的相关代码是一致的。
可能会有同学说，不行啊。我还要改 module path。这点在现在也是已经支持的了。
如下命令：
$ gonew github.com/ServiceWeaver/template example.com/foo
gonew: initialized example.com/foo in ./foo生成目录：
$ tree foo
foo
├── LICENSE
├── README.md
├── go.mod
├── go.sum
├── main.go
├── weaver.toml
└── weaver_gen.go对应生成的目录名是指定的 foo，创建出来的 go.mod 文件的 module path 是：module example.com/foo。
符合上面提的要求。
一些讨论
结合讨论的内容来看，大家的反馈都是比较积极支持的。因为确实看到社区里很多人为此做了一模一样的事情，各语言都有，真的是各显神通了。
图片
有个别同学支持将本文提到的 go new 放到 go mod init 中，这样就不需要再单独创造一个新的命令集。
提出的同学认为 go mod init 本质上也是在引导 Go 应用的使用，和 go new 比较类似。可以调整为：
go mod init example.com/x/abc --template github.com/ServiceWeaver/template以此满足一样的诉求。
不过我感觉这命令就太长了，没 go new 那么短小精悍。
总结
本次 go new 工具的讨论和实验，Go 团队非常迅速。目测势在必得，肯定会加进去了。
因为根据反馈 Google 的几个团队也有兴趣尝试使用 gonew 进行模板化。ServiceWeaver 团队对此也非常感兴趣。
功能虽然非常简单，但基本满足了不同的团队为了不同的代码模板，创建一个新的模板的诉求。一旦成熟，也就不需要人均手搓一个模板的脚手架工具了。
后续各自在工具链套一下就 OK，一个快速的小成果就好了。推荐大家试用，又或是觉得还需要什么功能补充，也欢迎随时留言。
