事实证明，商业公司都是一个样。没有永恒的王权。开不了源就只能内卷

其实也可以说，开源是兴趣，项目就是这样。如果你想要更加进一步的服务，比如教你如何用好，甚至写代码都是可以的，只要加钱。比如 5k 写几个 use case 还是很好的。
代码是自由的，但是人工服务本来就没有提，所以适当收费也是好的。

@bequt http client 可以去 awesome-go 上面看，好一点的都是基于 Builder 模式的。性能我就不知道了。
不过一般没啥特殊要求，我一般都是使用标准库中的 net/http ，毕竟没有外部依赖。仅供参考

@stirlingx rust 除了被编译器干，还有编译速度，其他都是挺好的。你会玩黑魔法有黑魔法的玩法，不会玩黑魔法有不会的玩法。丰俭由人。还能各种定义 DSL 。官方库在一些基础的地方也做得不错，比如自带一个 utf-8 编码的 String

@zwpaper 又想开源又不想让人商业？那你写 EULA ，商用请联系你获取授权不就得了。跟 Unreal 那些商用软件一样。只要人家用了你的代码就是侵权，看可以，但是用不可以。

@Red54 开源协议我看就没有限制商用的，因为限制商用也是一种“不自由”。所以基本上都是在让你商用难受上面做文章。

至于 unreal 只是给你看代码，人家出的是 eula ，他们可不是什么开源项目。只是让你有查看源代码的权利，代码版权还是属于 epic 公司，同时你要用的话，就要按 eula 地走。

当然了除了这些版权问题(copyright)，现实中实际上还会牵涉到专利问题。比如特定软件实现是有专利的，哪怕代码是 GPLv2 ，一样有可能被专利人起诉。

@PrinceofInj 不是魔改的 hyper-v ，是魔改的 windows ，windows(Xbox 主界面）跑在一个 VM 里面，游戏跑在一个 VM 里面，最低底层是 hypervisor 。其实你在 windows 里面开启了 hyper-v 也是这样的。开启 hyper-v 要求机器重启就是这个原因。
理论上这样破解要求程序突破虚拟化限制，实现虚拟机逃逸，有这本事，怕是单纯这个漏洞就能值很多钱了。

游戏机性能高其实不单单是因为这些技术。还有就是硬件是他们主机厂去定制的，他们对硬件非常了解，同时还养着一批很厉害的程序员，他们写的驱动就是比 AMD 的强（ AMD 的软件部门不行啊）。

@monster33 Xbox 有啥性能不好，显卡都可以直通，硬件还是自家定制的，驱动什么的自家写。磁盘基本上独占，虚拟化基本上就是干 CPU 跟内存的活，这两者恰恰是最适合虚拟化的，性能高到跟宿主机比可能只有 5%以下的差距。但是这不完全是虚拟化技术的功劳。

现在都这么多年了，这些虚拟化技术其实都是很成熟。性能基本上不存在什么差距。基本上都是生态决定了用户用什么。
比如有些设备就是没有适合的驱动，我的设备就是支持 kvm 不支持 hyper-v ，你能怎么办？所以你是玩高端硬件的，有钱买 ESXi 可以，还有人帮你擦屁股。微软的 Hyper-V 同理
KVM 适合那些极客，只要你技术厉害，不管是二次开发还是支持最新或者老旧的硬件都没问题。毕竟有源码，有文档，你可以自己动手。大公司很多时候选 KVM 也是这样一个原因。

大公司成百上千台物理机服务器，VMWare vSphere 跟 Windows Server 可是按 CPU 核心算钱。自己又有钱又有人，为什么不把这些钱花在自己的团队身上？

一般家用自己喜欢折腾的，上 KVM 吧，你想玩什么都可以了。

@Rocketer 大家其实都属于一型 hypervisor ，都是直接跑在硬件上的，kvm 本质上就是把 linux 内核变成了 hypervisor 。所以驱动做得好，有硬件虚拟化指令支持，虚拟化性能都很高的。

如果你目标平台是 Debian 系的 Linux 发行版，那么请使用 dh-virtualenv 工具构建一个 deb 包作为构建产物。
此方法是我认为相对较好的了。同理 Redhat 系的也可以去寻找相类似的工具，原理还是构建一个目标平台的包。

这种方法的优势在于，
1. 可以完全在构建机器上完成构建。
2. 对系统依赖极低，基本上只依赖 CPython 解析器，同时如果依赖第三方库，可以通过发行版的包管理器解决。
3. 打包的产物基本上就是你要部署的文件，一般情况下可以做到比 Docker 镜像更小
4. 可以编写 Systemd/init.d 脚本，部署的时候一并部署了，完全做到通过系统命令来管理程序生命周期（ start/stop/restart)
5. 可以更加容易地部署静态资源文件，而不用考虑资源文件在项目中的组织或者所在相对目录

如果是为了管理以及部署方便，可以使用托管型的 k8s ，据我所知，各大云服务提供商都有提供。好不好用就不清楚，不过基本能满足你拉代码就能跑的程度。当然了，你还是要写一个 Dockerfile 用于构建能运行的镜像

@markgor edge 可以在 linux 上面跑的，你这个问题不成立的

@katsusan b 是可以永远不为 nil 的，因为这是类似 C/C++那套，函数不帮你分配对象，你得自己分配好传进去。至于如何判断错误，加个返回值作为判断操作是否成功就好了。

据我了解，Django 是一个请求对应一个数据库连接，你这边的数据库多线程查询是如何连接数据库的？是自己重新创建连接了吗？

不要动不动就反思，这个问题不单单是中文网站索引的问题，英文的也是一样的。Hacker News 上面有人讨论过了。内容农场一直都存在，只不过谷歌调整了排序算法，导致这一批内容农场排在前面了

只是开发的话,MariaDB 其实问题也不大。他们更多是存储引擎的优化倾向不一样。上层使用者应该是无感知的。

data mapper 跟 active records 是两种 orm 的设计思路。没有优劣，只有合适跟不合适。

很多时候人家不做的功能不一定是他们懒，是有些功能本来就是几行代码的事情，库留给你自己实现。而不是强迫你接受它的实现。比如异步。
sqlalchemy 很多功能依赖于底层同步的数据驱动，上层如果硬是要全盘走异步。那么就是需要 sqlalchemy 帮你维护线程池。但是库并不是专为你服务的，还有很多项目是不需要异步功能的。所以它留给你自己选择。而不是出厂自带。毕竟用不了几行代码封装。

至于说自己 sql 写得好的，我见了很多其实都是“我会写 SQL”的水平，所以不要觉得自己写 sql 玩爆这些 orm 框架。当你要有一些变化的操作，你 sql 就很容易拼接起来，你真的能保证你的 sql 拼接处于一个很高的水平？这个时候也许你就走在写一个坡脚的 sql builder 或者 orm 框架的路上了。

觉得有问题，可以多去了解项目的变迁。如果你觉得我就是一个 curd boy ，不需要了解这些工具的历史。那么我只想说你自求多福吧。或者这些工具从一开始就不适合你用。也许其他的会更好。或者你也可以自己重新写一个。
计算机领域没有什么永恒的，有 apache web server ，也会有 nginx 。有 memcache ，也会有人去写 redis 。只不过很多人并不是写出一个更好的罢了。所以了解历史，从中汲取经验，避免掉坑也是一件好事。

@vkbo 不是，优化得好的话，60 帧一秒的刷新率还是可以的。图形是用 skia 作为后端，Jetbrains 另外封装的。理论上来讲，比 Electron 轻多了。