- 主题:把js全干掉,统一成ts,有没有搞头?
对比其它支持线程的编程语言，js 不支持线程，天生异步，是唯一能够实现隐式协程的编程语言，这是它得天独厚的条件。但 js 选择了盲从，错失了一个机会，真是替 js 感到可惜。
协程不是什么新东东。微软在 win2k 时代之前就为 windows 增加了 Fiber 系列函数，用于 ms sql 的源代码中。
但协程之所以一直没有普及，是因为协程是 all or nothing, go 抓住了机会，js 没抓住。
我也可以断定 rust/kotlin 的协程必然也不好用。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 哪怕io操作都要协程化，为啥所有函数都要async？我写个1加1纯计算函数也要进事件循环？
--
FROM 124.72.119.*
你那个 fiber 的那句话就是错的。说跟 mssql 相关是 msdn 的原文，不过我一时半会给不出出处。win2k 还是 win98 时代就有的我忘了，内部先用的，后来移植到 win32api.
async/await 也不是啥新奇玩意儿。python 原本支持的语法叫 yield from 完全等价于 await，当年 python 改动关键字的那个 c 补丁我都看过，没几行代码基本就是数据结构改名和增加关键字就完事了。再早的是 yield 实现的，搭配 twisted inlineCallbacks() 使用，更早的话，十几年前 eventlet 和 gevent 就非常成熟可应用在生产中。
但是有一说一，确实是 c# 首先使用 async/await 这个关键字。
这俩关键字，对于 c# 都是好东西，对 python 和 js 都是大毒药。
【 在 leadu (leadu) 的大作中提到: 】
: 老鱼你这俩个和c#相关的帖子都似是而非的，简单聊聊相关历史吧
: Fiber：纤程基本没人用，而且也未必和sql server有关，那时候怕还是sql 7，sybase开发的
: 线程池类型的协程：xp加入了一个win32 api QueueUserWorkItem ，就是个Windows给各个语言提供的线程池，
: ...................
--
FROM 124.72.119.*
这个事情在编译器里面几个判断语句就搞定了。实际会优化成正常的函数调用。更深层的优化可以放到字节码这个地方，直接切换函数帧，不止不增加开销，甚至提升了性能。
话说，js 社区啥时候也关心函数调用开销了。。满世界到处飘的 lambda 和 map()...
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 这个，一听上去有点道理，细思极恐。你这个主意其实就要求所有的系统和用户代码都以默认await为前提，每一个操作相当于都要try catch。真要这么搞，我觉得写代码状态复杂度和时序考虑复杂度就要爆炸了，跟现在写并发程序有点像了，
--
FROM 124.72.119.*
我前面说过了啊。。
python 有 GIL，约等于不支持多线程。python 日常使用的多线程，通常是用于阻塞 IO 的。
现在只要把所有的线程阻塞 IO 都替换成协程阻塞 IO，把 threading 模块替换成接口完全一样的 fiber 实现，那大多数 python 源代码，就可以在完全不修改的情况下，使用协程了。
关键是这事，我们以前用 gevent 的 monkey_patch 已经实践过了，完全可行。
当然了，有 C 库的兼容性问题，比如 c 写的那个 mysql-client 就不行。我们试验 pgsql 和 pymysql 都是完全没问题的。如果官方定下标准，c 库跟着改，很容易改过来。最佳的节点是 py3k 就改过来。
可惜龟叔选择了 async/await，这俩关键字到处传染，把源代码变得非常难看。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 为啥对python也是毒药啦？
--
FROM 124.72.119.*
这个是业务逻辑问题，只是个语法糖。愿意使用这个语法糖就要 try/catch，不愿意使用这个语法糖大可不必。
一般说来 rpc 也不会设计成 setter 调用。像我在 jsonrpc 里面是这样玩的：
remote.userService.createUser(u);
上面那一句话会判断 userService 是否在远程存在，然后下载方法签名缓存起来。
多方便啊。。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 你理解错了，不是编译问题，是用户代码写起来爆炸。就拿你说的那个例子，能通过网络调用拿数填给proxy，那我岂不是写一个赋值有语句就得catch一下网络错误了。。。简直就没有一句操作是安全的
--
修改:hgoldfish FROM 124.72.119.*
FROM 124.72.119.*
那你也可以说异步 IO 对 JS 也不是规范，不永恒。
事实上，ffmpeg 作者 Fabrice Bellard 大神写的 js 就没有异步 IO，而是直接调用 libc 函数。
又以及事实就是 cpython 这么多年都有 gil，刚好可以无缝切换到协程去。把多线程留给 c 库去实现。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: gil不是规范，也不是永恒的
--
修改:hgoldfish FROM 124.72.119.*
FROM 124.72.119.*
stackless python 是 1998 的产品。。
【 在 leadu (leadu) 的大作中提到: 】
: 改名没关系，就当yield from是async。
: 为啥根据python2012年加的yield from功能，说dotnet2003年的不是啥新鲜玩意？
--
FROM 124.72.119.*
我玩过一堆的 js 解释器，像 java 的，kjs 的，还有 ffmpeg 作者的那个 quickjs，压根没人去实现什么事件循环和异步 IO
不用你给我普及 python 的知识啊。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 事件循环和异步io是bom和node的规范。
: gil不仅不是python规范，而且现在就有很多也不小众的解释器里面并没有gil。cpython里面想要解决gil的呼声也一直有
--
FROM 124.72.119.*
不用我设计语言。。
是我在 python 和 js 里面早就是这么玩了，包括你刚才看到的 rpc 的写法，都被我用在生产项目里面了。通过小几十万的日活的检验了。
我说的是不过是一些被玩烂的陈年老梗。只是我希望 js 和 python 能再加强一点，让我用得更爽一些，可惜我看是没希望了。
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 好在没让你来设计语言。。。。汗
--
FROM 124.72.119.*