@lzvezr 版本不同没关系啊，我的意思是，难道不能同版本只留一份吗？一个统一的存放目录，xx 框架 1.0,2.0，3.0 各一份，其它项目想引用哪个版本就引用哪个版本啊，为啥非要像现在这样，一个项目下下一次 xx 框架 1.0。换个项目又下一次 1.0 ？

@KuroNekoFan 请问一下，npm5 到底能不能实现共享的依赖？如何实现？

@karnaugh 这个难道不能在全局路径下 vue1.x 和 2.x 共存吗？这没什么吧，大部分包管理工具都是这么干的，多版本共存，每个版本只留一份

@wesnow .net core 其实已经获得了远超之前.net framework 的发展。事实上在中国以外地区的商业领域，.net core 现在过的非常滋润。但是国内 Java 十几年来积累的生态和人口优势，哪是那么容易打破的。所以不要和大势怼，啥合适就用啥

为了工资，赶紧转，没啥说的，打工就是面向工资编程。反正我现在对外工作仍然是 Java，自己干的时候就开.net ，两不误

不需要坚持，当程序员是一种爱好，我一向认为没有爱好最好不要当程序员，否则你撑不下来的。最重要的，从来就没有说过一定要把爱好当工作，我会写程序写到我死为止，但是我现在已经开始转型做程序员以外的工作了，这就是爱好和工作的区别

Go 还是个很年轻的语言，所以有些设计上的问题是很正常的各位，不要神话一门语言，就算它是 google 发明出来的也一样。具体到楼主的问题，我个人的看法是，Go 最开始是设计出来取代的 C 的，非常偏底层，所以字符串这块的抽象就不像其他更高级的语言，我个人认为这个可能会和 Go 的价值取向有关，如果 Go 以后打算进一步去应用层，那么迟早会变的和其它高级语言类似，如果 Go 的想法就是扎根底层，那很可能也就是这样了

@agdhole java 做 web 现在眼光看，真 tm 重。
.net core 我觉得目前发展的挺好，做 web 非常舒服
go 目前的开发流程，还是更接近 C 这种纯粹编译源码的方式，虽然它确实编译快。但是应用级的开发，其实是很依赖包管理器的。所以我个人觉得 go 目前还是更偏向靠后一点的地方，现在大部分公司用它也是做中后台的 rpc 服务，并没有让它用在直接面对前端的前台。

@blless 我觉得 go 什么时候能把包管理解决了，它就没啥缺点了，目前那个 src path 真是让人很不舒服

你一定要记住一点是合伙人这个东西是一定要讲钱，讲利益的，不谈钱，不谈利益，那不叫合伙人，那叫占你便宜。早点离开，这种人就算以后发达起来你也不会从中收到利益。别指望什么将来有合作？连当下都不能满足，何谈将来，所谓的将来都是大饼

你熟悉 go 后就会发现 go 这玩意开发起来的手感就像 C，不过比 C 还简单。不过我个人觉得这东西目前还是不适合做 web，适合做更核心一点的功能，而不太适合业务层，因为没有包管理。所用的引用都是源码编译

认真的说一下，编程属于技术行业，凡是技术行业，都有如下特点：
1.绝不可能靠任何简单的方式大量培养人才，如果有这样的方式，那么大量产生的“人才”会迅速抬高门槛，直到门槛高到简单方式失效为止。
2.因为理论 1 的存在，所以在技术行业你要想爬到一个能够超越大多数人（越过 50%吧）的位置，一定是艰难的。如果不艰难，其它人也能迅速的复制你的成功，导致你迅速的失去你超越大多数人的位置
3.资本非常聪明，所以它也会想尽办法，抬高技术行业从业人员的技能门槛。这样能保证它用尽可能少的薪水雇佣水平更高的人。这就是培训行业存在的理由。
所以，没必要说培训行业的不是，它是简单方式，不会培养人才，但是能迅速抬高门槛，满足资本的需要。

对于个人开发者来说最大的好处是环境隔离，无污染
部署的便捷性要成百上千台机器的时候才体现的出来。k8s 对个人用户不是刚需，但是隔离环境这点确实是刚需

少学习框架，多研究原理，前端还处于群雄争霸时代，淘汰非常快的，但是不管你出什么乱七八糟的框架，基本的原理是绕不过去的，那些东西决定了这些天花烂坠的框架的上限

我说，这玩意，不就是 asp.net 里的 webform 吗

@testplusplus openjdk 目前的发布主力依然是 oracle，而且 openjdk 的二进制维护时间连 6 个月都没有，新版出来，旧版就放弃，只给源码，你自己编译去