@
mengzhuo 感谢回复
这个语言内置的官方库目前来说感觉比 Java 好用。很多东西写起来也比 Java 简洁，这个是我觉得还不错的地方。
关于 1 ， vendor 我们已经在用了，这点解决了多个项目不会依赖同一个版本的第三方库的问题。
而这里其实是想说的是，一些第三方库没有语义化版本没有 tag 的问题，比如 redigo ， github 上是看不到语义化版本这样的信息的， godep 导入进来后，记录的是非常长的 git 的 rev 信息。可能有人会说，作者能确保每次合并到 master 上的一定是稳定的版本。但没有语义化版本，有时候很难向别人解释为什么我当前要用这个版本。如果库之间有依赖关系，也很难看懂他们的依赖关系， A 库如果依赖 B 库，那么依赖的是 B 库哪个版本对外的接口？所以库缺少语义化版本，可能会对未来项目的长期维护造成麻烦，我们不敢随便升级库了，因为不知道是否有 API 的不兼容。
关于 2 ，没有私有仓库，只是觉得不方便，到不是什么大的问题。 godep 和 maven 在使用上还算接近。希望有组织能早日实现个私有仓库。之前写 nodejs 的东西，在中国这个大环境下，考虑是否将 node_modules 中的文件提交到版本库简直是噩梦。提交到项目版本库的话，项目要多几万个文件。不提交，根本没法获取依赖。
关于 3 ，是我自己说的有点问题，其实是想说没有抽象类的机制，一个接口有很多实现的时候导致要写许多重复的代码。 interface 的话，的确用起来比 Java 灵活很多。所以两者比较，感觉也没啥，多写点就多写点吧。
关于 4 ，我写过几年 C++，写过几年 Java 。 golang 的这种不加星号就不是指针的变量声明方式间接的引入了变量不可变性，不过在函数式编程没有普及开来的情况下，变量不可变的意义就不是太大了。所以就会发现周围的人为了实现功能以及为了以后维护省心点，写着写着，所有的方法或函数的参数都变成了传指针了。很少有人会认真考虑从我这个接口传进去的结构不能是指针，因为数据在内部是不可变的，并且产生多份数据对内部更深的代码是没有影响的。如果大家声明的所有变量几乎都是指针的话，个人感觉语法反着来可能更舒服一点，即一切皆引用（指针），当需求明确了或需要优化或结构数据不能在方法内部被修改时，再考虑将方法参数明确修改为值传递。目前很多其他语言也是这么实现的吧。
当然，现在 golang 有这种现成的变量不可变机制的话，也希望 golang 能更早的实现出可用性很强的函数式编程的范式来。
其实正如楼上各位提的， golang 语言本身 ok ，习惯了问题不大，目前感觉阵痛主要还是因为配套没跟上。