看了最后面的拉钩网，我承认这是一篇很成功的软文，甚至让我觉得这完全不是一篇软文。
这篇文章我给 99 分， 1 分不给怕你骄傲

@tanteng 不会， redis 就是一单线程实现，所有操作都是顺序执行

文章其实还好，但是觉得没有深入到根基，其实去重算法我觉得基本上就是基于 hash 的，还有神奇的 bloom-filter,当然也有简单暴力算法。
还有就是改变数据类型这个我觉得不是事吧，你在暴露的接口那里，再转换回去就好了嘛。你算法内部的数据结构怎么会是一个问题呢？关键是你要给出对应的时空复杂度，那才有讨论算法的价值。

这个问题好，若是想不用 GIL ，那么已经有一个很好的例子了，那就是 Java 的实现。那可是伤筋动骨的大改造。

新手没有办法，压缩混淆就好了。剩下的都是屠龙之
技，要求会 C++

用 Numpy 请一定要用它自带的矩阵数据结构，不要 list 套 list

rsync?

@ivenvd 托管语言这个我还以为只要是有虚拟机的都是这样叫。反正我的意思就是指类似 java 或 C#这样的语言。

简单的项目是简单的项目，但是包管理必然是通用的嘛。复杂的问题解决不了，只能解决简单的，那么这个完全没有推广价值。最多这个世界上会再多一种包管理器而已。

若是要问我支不支持，我说一定支持，不过仅仅为了下载源代码的话，我为什么还要去学习一套新的包管理器的操作？编译，依赖还是要我人肉去解决，然后却说这个包管理器很好？

若是要说是源代码代码分发平台，仅仅用来交流的话那显然是有一个统一的平台好。但是交流平台就说交流平台，不要尝试包装成包管理嘛，明明包管理就没做好。

公司内部的话，我建议可以如轮子哥所说一样，仿照微软，什么都往版本库里面放，只要一 check out 那么就可以编译了。包管理什么的完全是在开发阶段人肉解决。

@ivenvd 托管语言大多数基于自身的虚拟机，那已经抹平了系统差异，那么其专有的包管理器的确有存在的必要。但是 C/C++这些本身就在造轮子，写特定平台的。若是要写起包管理器，出来的效果跟我们平常用到的也是很大差别的。

比如，到最后开发者还是得装了 6 个版本的 C++编译器以及对应 10 个版本的 STL 库。包管理完全没有实现统一开发平台的作用！最后还因为不同的库编译器不一样而头痛。

@congeec C/C++的包管理并没有什么用，若是真有用的话，那它就不应该叫 CPM ，而是 apt,yum 。你想想嘛， C/C++写那么多东西都是平台相关的，那么这个包管理的意义何在？还是一样的自己管理啊，而且 C/C++各种编译方法啊，有的库用 CMake ，有的是 GNU Make 。
C++换个编译器都会报错，不同的 STL 会不兼容。因此我觉得 C/C++这些语言的包管理意义真不大。

npm 那水平就不要拿出来说先进了。遇到有需要编译的库，大家一样容易挂。还有 npm3 之后才开始了扁平化各类包。之前各个库自己管理自己的库，不断嵌套，在 windows 下还爆出了目录嵌套过长挂掉的情况，一个依赖下载几十兆。当时我真是大开眼界了，没想到包管理还可以这样做。真是简单粗暴啊！

现在的 npm 才说好点，说其他包管理追上它，那真是一个直钩钓鱼。

@dyingbleed 大概青云是将工单接入到 slack 之类的服务，全部人都看到

@tanteng 一个是全部读到你 Client 端的内存里面，在 Client 端以一个数据结构或者对象的形式存在。一个只是一个迭代器。
简单而言，内存消耗不一样。

虚拟机逃逸这是大新闻啊，若是能做出这样病毒的人，赚正当的钱都可以达到上百万一年了。黑产只会更屌， LZ 你相信我，这样的人凤毛麟角。你不会遇上他写的病毒，若是你是安全研究员，那就当我没说

推荐 gitlab,bitbucket 是一个半成品。 gitlab.com 上面跑的是 gitlab ee

@vus520 没成功是怎么表现啊？加个 z 不是仅传输的时候压缩而已吗？

貌似 Java 8 开始， OpenJDK 是标准的官方推荐的实现，也就是说 Oracle JDK 也是基于 OpenJDK 的， Oracle JDK 最多就是在图形性能上有优势，若是为了学习 Android ，那么上 OpenJDK 完全没问题，还有一个就是 API 神马的是一样的

@vus520 青云的功能都比不上 AWS 跟 Azure,不过在国内青云的确是一个不错的 IaaS 。

其实青云也就仅仅比较完善地完成了 AWS 网络那部分，你对照文档，很久就能迁过去了。青云基本上都是自动化管理的东西，迁移起来好迁。