@coolmenu 的确是这样的，这至少说明.net 生态卖闭源组件的确能活下去。

之前看过 rdp 的相关资料，其实 rdp 是会在客户端进行被控制端的 GUI 绘制的。不是直接传输视频的类型，因此如果有观察 windows 下微软的自家实现，可以看到流量的使用并没有那么大。
然后 rdp 其实是微软自家搞的，有微软的专利。没猜错的话，应该是微软那边有特定专利下的高效实现，如果不申请授权大概是没法用。这就导致了为什么 rdp 客户端的体验差别那么大。
如果感觉卡，其实可以换不同的客户端试试

@sadfQED2 这功能理论上不依赖 go 实现。C/C++是有的，叫 rr 。不过实现调试的时间穿越功能对性能已经并发的影响很大，如果语言本身没有开洞，怕是不好搞。

@haoliang 请看我 25 楼的回答，我早以指出所谓的异步调用可以用现有的标准库封装线程池实现。
同时本帖的重点并不是什么异步同步之争，本身问题是基于 Python 环境的。一个底层是线程池封装的异步调用真的会比同步的多线程更高效吗？我表示怀疑

@wamson 你这样说的前提是你的数据库顶得住那么多请求啊，你的数据库明明就只能接收 10 个请求，你这边应用端发 100 个过去，那么你是不是应该有 90 个请求快速返回了，然后报错？切出去 CPU，不就变成用于回来处理这些问题？并不能合理利用 CPU 等待 IO 的时间嘛。要不你说说这个情况如何解决。
我并不排斥异步，但是我觉得异步要分开场景。数据库请求对于异步的要求我觉得不是那么大。很多数据库顶不住你的大量查询请求。

WX: bmVvX2JsYWNrY2Fw

@hjahgdthab750 单单官网底下就说明了该数据库驱动是有连接池在底层的。异步调用的需求肯定是有的，但是这不是必须的，python 还有 asyncpg 。

@wamson 你做过 benchmark 吗？你大量的数据库查询请求是怎么发给数据库的？如果多了要排队，那么跟同步有什么区别？纯粹只是调用的区别嘛，你现在也可以自己简单封装一下，标准库已经有这样的组件可以让你将同步的函数封装成异步的

不是什么都应该是异步的，数据库操作异步，跟线程池有什么区别？又不能提高并发量。本质上只是为了使用者的个人偏好搞异步封装。
实际上这样的做法，我认为会掩盖了事物的根本，到时候出问题，又得去连接池的地方找问题。看了那么多的其他语言实现，数据库驱动这部分，大家基本上都是连接池的一套，同步操作的

WX: bmVvX2JsYWNrY2Fw

只是让 datetime 类型支持 json 格式序列化的话，直接实现 encoder/decoder 就好了，不管是 go 还是 python 的标准库都可以支持这个操作。

@toptyloo VPN 有赞助的，做才能拿到钱

你提 PR 合并到主线，你的提交出现了冲突，当然是你要解决。

Mongodb 我不知道，但是 Cassandra 我倒是可以说说。因为传统的关系型数据库在面对海量的写入的时候会有问题。所以人们为了获取更高的写入吞吐量，就开始分库分表，然后就产生了像 Cassandra 这样的分布式数据库。对一致性的牺牲，获取可用性以及更高地写入性能。
Mongodb 大抵也是类似的情况，虽然最开始是说它自身的无表特性。不过它的集群功能也的确比传统的关系型数据库要来得好一些。水平拓展更加容易。

@wh469012917 join 的问题在于你把业务压在数据库层面上了，这个看规模。有的公司倾向于在代码层面上面解决这个问题。用不用 Join 得看情况。因为如果换底层了，count 的方式可能比较好改，join 的方式就不见得那么好改了（比如加缓存或者换数据库存这部分的信息）。

@missdeer C++写跨平台问题不大，很多大公司都是这样干的，共用的逻辑用平台无关的 C++写。UI 用对应的平台 API 重新实现一个

@LeeReamond NUMA 呗，系统是有对应的 API 提供的。调用不同的 API，运算当然是不一样。还有就是 SIMD 指令，小核可能是没有，或者弱化

事实上 Windows 有自带的 Http 请求 API，完全可以什么第三方库都不用，只用 Windows 标准库就可以了。而且 msdn 有很好的文档以及例子。
当然了，微软的 API 好不好用则是另外一回事。

视频转码用 FFmpeg 啊，没有另外的选择了。大家都在用，其他语言也是对它的封装