@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 轻多了。

你喜欢 M1 macbook pro 可以自己买，不要拿到公司干公司的活就可以了。上班就用公司配发的电脑。

@jackiejkl 我的意思是 map 是内置的，好比你对数组也只能用[index]这样的方法取值，而不能使用.index 这样的方式取值。它本来就是语言的一部分。语言就是这样规定的。
至于为什么提到 make ，因为 make 就是一个看似违反函数调用方式的存在，它一个函数可以有多种函数签名。本质上还是语言作者自己开洞实现或者说这就是语言的一部分，“我用可以，你们使用者用就不行”

运算符重载的例子你都举得不对，map 等内置数据结构当然可以用下标比较。因为这是语言规定的一部分。要举例子啊，你应该举 make ，毕竟它可以接受数量不一样的参数。你试试看能不能模仿

我觉得很难，毕竟之前有 CentOS 透露过，自己编译的产物的确性能上不如 Redhat 的。因此我觉得编译参数这东西应该是不能作为违反 GPL 的证据

@evilStart 谷歌家有自研的 IDE Cider ，结合他们自己强悍的搜索功能，真的只是写代码就可以了。写完代码就分布式编译，回归测试，打包
应该本质上跟 vscode 差不多，不过其背后是谷歌自家的基础服务支撑，哪怕开源使用体验也是达不到他们家的水平

wsgi 模型不支持你这玩，你要这样玩，其实是要求 wsgi server 支持进程管理。uwsgi 可以帮到你。也许 asgi 也可以做到，不过得看你的代码，如果按 wsgi 模式写的同步代码，建议上 uwsgi 解决这个订阅问题就算了。事实上相当于两个独立进程

@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