用过 heidisql , navicat, dbeaver , dbvisualizer 个人体感 dbeaver 最好用，免费，关键词提示比较好，数据库支持多，高级粘贴也很实用(不过多表联查结果中修改数据曾碰到过 BUG)。dbeaver 也是我用的最后一款，不排除其他软件现在更新得更好的可能。

使用 nonlocal 引入外部变量

1 '使用 BIO 上下文切换厉害' 可能是说高并发时多个线程同时运行时的抢占，很多时候其实请求逐个完成就可以，线程频繁切换影响性能。
2 对于长链接应用，开很多线程是比较常见的，如游戏服务器，聊天服务器，开上万个也不是不可能，此时内存消耗就比较大了。
3 select 是通过一个线程监听多个文件描述符状态变化的，因此除非高并发优化否则没必要开 10 个线程去 select

@3dwelcome 多个子数组拼成大数组不就是数组组成的 list 了吗。实际优化过程中也是可以采用数组组成的 list 来实现速度和存储的平衡的。
数组插入比链表快是利用了高速缓存的特性，但有些嵌入式设备高速缓存都没有，链表的优势就体现了。

@GeruzoniAnsasu 从 C 源码生成对应语言 glue 的库也有不少，比如 swig ，不过不像 go 是集成进编译器的。plugin 发布的很早现在也没什么动静，感觉没法指望。。
不过动态性我用 python 就能满足需要了，还有 Jupyterlab 这种能发挥动态性，把 python 当 shell 用的神器，所以也不期待 go 的动态性能做成什么样。

工作之外的话，为了更好的糊胶水，先什么语言都学点，然后主要拿 python 和 c/c++黏。。

@GeruzoniAnsasu 要说用 C 的 ABI ，感觉很少有写起来痛苦的，C++ extern "C"最简单，python 有 ctypes ，jvm 系有 jna ，node 不太了解但感觉大部分语言套上 libffi 都能搞个不错的。Go 的工具链倒是真的简单，但是 Go 的动态性太糟糕了，plugin 到现在依然不支持 windows

@wheelg 下载安装默认认为用户知道自己在做什么，或者交给操作系统，比如 IOS 你要发布应用要经过 App Store 审核才行。当然现在浏览器也有了不少像 FileSystem 这样的扩展浏览器边界的 API.

记得之前看 react 的教程好像就是做个井字棋

估计是 Windows 找到版本不一致的 g++运行时了。。详细的可能要查 PATH 变量了，或者调试器调一下

动态引入依赖还见过更 tricky 的方式是加入到 sys.meta_path ，在 import 到的时候发现没有再去下，比如 http_import 啥的

前几天我在某杂牌机上装的支付宝倒是会卡住，ps 看了下好像是内存用挺多的。不过我觉得大概是杂牌机系统魔改的问题所以没管(又不是不能用。

不知道可不可以 hook 住内存申请释放的函数 malloc mmap 啥的去查。

我前段时间也整了个 RPC 来着
https://github.com/Pursuer2/PxpRpc
真实极简，到目前 IDL 都还没有，就给客户端做了个方法签名...
主要目的是不同语言 /平台交互用的
谁还能更轻量？(

lua 有带类型系统的版本
https://github.com/teal-language/tl

还见到过 typescript 到 lua 的转译器
https://github.com/TypeScriptToLua/TypeScriptToLua

@weakish 匹配和自动转换通常要语言有类型系统才行，类似 Java 和 C++的重载。Python 没类型系统，Type Hints 也是后面加的不能影响这种原先设计的语法，自动转换无法避开我上面提到的传参时的歧义。当然函数实现者还是可以通过 type(args[0])判断并做自动转换。

@moonkiller 抱歉没细看。其实还有你的“突然好奇”是从哪里来的，我想有可能是你受到了某些外部信息影响，那这个外部信息就是整个事情的起因，比如同事 /周围有人搜索 /查看，晋江打广告波及到你等，这些也可能让你所在 IP 段被标记

这是有语义上的差异的。函数可以接受不定长参数，你传一个元组，函数要如何区分你要把元组作为一个变长参数的第一个参数，还是要把元组拆成变参的参数?

我已经看到过很多说自己聊天内容出现在应用推荐里的情况了，不过到目前还没见到例如
"检测到 APP 在非必要场合使用录音的 API"
这样的有力证据。

实际上只要联网搜索 /查看过什么东西，账号浏览器指纹 IP 都有可能被追踪到一些信息。

@secondwtq 有无虚拟机通常不是语言决定的，是语言生态决定的。
我觉得这些应用生态的核心差异还是，应用发布时，只打包应用所需的东西，还是尝试复用终端设备的资源 /程序。前者可以实现小的单一应用体积，并解决依赖问题，但是多个应用之间就可能存在很多重复的资源(极端情况举例，现在的应用没事就整个 CEF/浏览器)。后者一开始就需要用户安装一个比较大的运行环境，后面还可以安装其他组件，可以充分复用资源，相应的也要面对 运行时大，依赖管理难的问题。 大部分 windows 应用和 android 应用和 go,c++(除 COM 技术外)的生态就接近前者，linux 包管理和 python ，java 生态就是接近后者，。我倒是倾向于后者的发布模式，但对于普通用户来说，前者确实更友好。

和 jupyter lab 比如何？我还是比较期待 jupyter lab 演化出的 IDE 的扩展，像 jupyterlab-lsp 之类的