C++是一个多范式的语言，C with Class 本来就是预想设计的一部分。用好它一点问题都没有。
不是说 C++就一定要泛型到处飞的。
虽然现代 modern C++一般都会使用更多的泛型，优先使用组合而不是继承。
至于优秀的设计，不是很建议直接看那些大库，建议看看小项目。要不去看看腾讯开源的 libco?

互联网公司会有 C++的需要的，一般都是基础设施服务，当然也有一些业务是用 C++写的，比如搜索

@Licsber 生成随机数都是平台相关的，不同平台产生随机数的方式不一样。有的是调用所谓硬件提供 RNG 生成，有的是多种熵源生成。语言自己不提供也很正常。

@Osk 是 wsl1 跟 wsl2 都用不了 systemd ，至少现在不能开箱即用。用到也是跟 Linux 下有些不一样的。原因在于 wsl2 的发行版得用微软自己搞的 init 系统，你不能替代它。而这个 init 也干了很多活。如果把它干掉了，现在很多功能用不了。

TCP/UDP 只是传输层协议，真正在用的时候会定义应用层的协议。那么应用层协议就对应 http 协议了。类似应用层就可以解析出一些关键字段，然后根据路由跳转。
当然了，一般都是直接用 rpc 框架来实现这些。一般情况下，开发者压根不用管路由。

上面很多楼已经说过了，哪怕是有 GC 的语言，现代垃圾回收器都会 pauseless 的类型。不会使主线程堵塞。
至于 C/C++/Rust 之类的语言，其实回收内存的时候已经不能称为暂停。因为这个是可预知。只能算成是程序 /函数运行的成本。更类似于你计算一个复杂的问题，函数没法立刻返回结果。

试试多线程 + ioloop

根据我的经验，信用卡或者支付宝之类方式给钱都是秒过的。邮件都是几分钟内就收到了。如果支付出了问题，大可咨询官方客服。Jetbrains 有负责中国区的销售人员，能解决问题的。完全可以用中文

@wellsc 连 luajit 都觉得性能消耗过大，那么就只能干掉网络 IO 。如果还要再 nginx 上开发，那么就只能上 C/C++/Rust 来开发插件。所以建议 Rust 写一个插件也不算不合适。
毕竟 cf 等企业，很多就是直接用系统语言开发一个插件，然后在 nginx/openresty 的基础上跑起来。

我不是很熟悉内核，不过这样的需求，是不是你用 eBPF 就可以解决了，不用改内核啊？

如果 MySQL 是你关注的点，那么请使用 Linux ，因为 Linux 是它开发的一等公民，MySQL 对 linux 的支持是最完备的。有什么问题，网上几乎也是以 Linux 作为默认操作系统。出于对日后维护的考虑，建议还是购买一台单独的 Linux 虚拟机跑 MySQL

@saltbo 没办法，没法动态加载库

做可以做，但是你这样搞，小心被说成学术不端。到时候你毕不了业才是问题

@kongkongyzt arm 服务器在国内也是有的，但是基本上都是裸金属，费用高。当然了这应该也跟 arm 虚拟化指令并不是那么完善有关。

@GYGYG 最简单的方法就是，你使用 tornado 自带的 tornado.tcpclient.TCPClient
当然你像二楼说的，你自己创建一个连接也是完全可以的，前提是你要把该连接设置成非堵塞，并把它注册到 tornado 的 IOLoop 上。

问题就是你把 socket 跟 tornado 混在一起了，tornado 已经帮你处理了底层 socket 的逻辑，包括 IO 复用。
你需要做的是在 on_message 里面写你的逻辑，并放弃使用标准库里面的 socket ，从而使用 WebSocketHandler.write_message 等方法

其实对照功能列表就知道了，如果你觉得 celery 给你带来的成本高于收益，很大程度你是对的，那么不用就好了。没有什么说一定要上 celery 的。
至于用 celery 的团队也没有错，有可能是他们首先比较熟悉。然后他们可能用到了 celery 的一些特性，比如既需要定时任务，也需要 job queue 。
没有什么选型定式，看个人需要。

@LeeReamond

1. 我的代码只能说解决 celery 能不能用 asyncio 的问题。

2. 既然你调研过 celery ，你就会明白你所说的并不是什么不可能的事情，就是需要额外提供一个基于 asyncio 的并发池，可以通过继承 celery.concurrency.base.BasePool ，并实现对应的接口。既然 gevent 能做到，这显然是可以做到的。但是你所说的共享连接池，等资源共享就未必。celery 是分布式的，worker 可以分布在多台机器上，你的需求本身就跟它的设计大方向矛盾。

3. 我理解你想要的回调应该是 rpc 式的回调，而不是在 worker 里面调用你的回调接口。你的回调是需要生产者配合的，哪怕现在 Python 绝大多数的人还是在使用基于 wsgi 的 web 框架。支持 rpc 式的回调，基本上就得在框架上面动手，不改支持不好。

4. 如果你所说的异步生产应该是指这个生产的动作会被你调用者的 IO loop 所管控的话，那么就是跟上面有着一样的问题，那么应该在很长一段时间内 celery 也不会改，这个同步异步需求可以使用线程池绕过。

5. 你的需求很好，但是这不是 celery 能解决或者解决好。这不是 celery 的问题，任何一个开源工具都没有说要对某一个人的需求负责。你如果觉得需求重要，有通用性的，那么你可以提交你的解决方案，或者提思路，又或者提供资金。我觉得退一万步讲，哪怕 celery 是个垃圾它也没有强制你使用。你完全可以选择其他方案，而不是发一个贴将它批判一番。自由软件是它已经提供源代码给你，授权你使用，修改的权利。一些个人需求，不代表就是社区的需求。