人怎么可能绝对理性，绝对理性的那绝对不是人

@kaneg 对，这才是 Linux 桌面的本质困境，Xwindows 这个老玩意的问题从上世纪一直喷到现在，没见人改

@zqx 你这句话的言下之意就是“市场都是白痴，看不到你说的语言特性高级”？

@cjh1095358798 没关系啊，程序员本身就不应该只困在一门语言里，我当初就是受不了 Java 的死板，投奔到 PHP 和 Python 的世界里去呆了两年，然后又被“重构火葬场”给恶心回了静态语言的世界，年轻就应该什么都试试，你试过才知道静态语言和动态语言分别的好处在哪里，翔又在哪里。
PS：程序员千万不要干的事情就是当狂信徒，问题是程序员又是技术工种里狂信徒特别多的行当。我还是建议你，两个都玩玩，没有你想的那么难的。等你两个都玩过，两个的翔都吃过，就会明白为啥 Java 这种简陋死板的语言能够在后端领域经久不衰了

@love 我当然知道 ts 这个东西啊，甚至我自己必须用到 node 的场合我都是尽量用 TS，问题是 TS 这个东西说到底还是要把源码编译成 js 的，ts 并不是 node 原生支持的东西。也许倒是可以期待一个 node 原作者搞的 deno

@love 第一代动态语言原本想要的是类型推导和匿名函数(Lambda)。然而它们过于激进犯了一个错误，把参数，返回值的类型约束彻底去掉了，不光 js 有这个毛病，perl,asp,php,python。全都有，谁也别笑谁，这也是为啥知乎有一个专门问题——为什么 2010 年前后诞生的语言(如 Golang, Rust, Swift)都是强类型 。https://www.zhihu.com/question/31100089

@cjh1095358798 多出去走走，看看广大的世界，不要因为自己身边用的是啥，就以为世界都是啥

从目前的情况看无类型约束的动态语言想入侵对安全性和稳定性有要求的领域非常困难，nodejs 可以吃掉 PHP 的地盘，但是 Java 的地盘。。。旁边还有 Go 和.Net Core 看着呢，轮不到 js 说话

楼主，我就说一句，注册表是 windows 的精髓，完全不愿意动注册表属于不正常的洁癖

@azh7138m 等一下朋友，我搜索资料过，说 NPM 现在已经能把依赖树扁平化了，只要依赖树扁平化，为何不能一个版本只存一份呢。你说的那些问题，如果 NPM 的扁平化依赖方式能处理，那么，只存一个位置——不管它放在哪里，都是毫无问题的。除非 NPM 的依赖扁平化也解决不了你说的：
P1 P2 依赖 D@1
P3 P4 依赖 D@2
你说的这个问题其实就是依赖不同版本，为了避免冲突，不得不用本地存放的方式来生成一个嵌套树

所以现在我感觉大家的回答很矛盾。我想问的是能不能“全部依赖放在集中的位置，一个版本只留一份”。而大家回答的是因为历史原因，容易出现依赖一个库但是版本不同的原因，为了应对这个问题，必须使用嵌套树存放，好像嵌套树才是 npm 必须使用本地目录存放依赖的根本原因。但是又有人回复我说 NPM 已经解决了这个依赖嵌套树，一级套一级问题，实现了依赖树扁平化——但是只要依赖树扁平化了，那实际就是一个版本只放一份吧。这等于说 NPM 依赖处理是可以实现集中存放的。还是说 NPM 的依赖扁平化并不是适用所有场景的？前套树在某些情况下还是得存在

@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 真是让人很不舒服