（我倒是不大喜欢 gradual typing，终归是一种无奈之举，在一些设计时候就没有考虑类型系统的语言上加装一个类型系统，其实挺累的。倒不如 static typing，写程序的开始脑子里就有类型这玩意了，而不是写到一半回头再装回来）
APL 是真的好啊，可惜快成为时代的眼泪了
我这种菜鸡只会把ts当java用，手写类型签名，当然偶尔也用下union type
所以用他干嘛，享受value restriction这些吗
TS 再怎么也是 JS 上面的类型系统啊，不如 ML 原生的类型系统啊
声明：没用过 Reason(
P.S. 前端圈的语言里类型系统好使的也就 PureScript 吧，然而这玩意能用来干活吗？
1 个赞
-
用 Reason React 开发图形界面。ReasonML 和 React 是同一个人开发的项目，有优先支持。
-
ReasonML 和 OCaml 的语法树等价，所以可以用性能优秀的 OCaml 编译器来编译。
-
从 Reason 编译出来的 JS 代码更像手写的。
ReasonML 跟 React 之间的联系是——React 的最初作者现在在开发 Reason。联系是在的，但不意味着 React（Facebook）对 Reason 的支持能有多高。
后两条确实是 BuckleScript 的优势（虽然我没理解 human-readable compiling output 除了证明编译器开发者的能力以外对实际项目有什么意义），所以如果是我，我会选择 BuckleScript 而不是（在 ML 系语言里再一个 JSX（来证明自己毫无创造力或者一味讨好 JS 开发者）的 ）Reason
讲真的不要把什么帖子都往 PL 上带啊（（（（
3 个赞
可是不用 JSX 为啥要用 Reason。
比如一起做项目的 normie 只会 JS。老夫得带带人家，不能给他们看不懂的代码，然而也懒得去教别人。
再比如 PureScript 那样用特殊的 calling convention 会让 interpolate 更麻烦一点。
都被骗进 Reason 了，其实再骗骗去写别的（真正好的）也不是不行嘛
能生成可读 JS 的只有 Reason 和更蛋疼的 Parenscript。不用 node 的更是只有 Parenscript。
不是啊，Reason 背后不是 BuckleScript 吗，不能直接写 BuckleScript 吗？
另外，你不会是自己写 Reason 然后生成 JS 做工作代码？
写 ReasonML 也能生成 OCaml，Reason 的语法还更 terse 一点少打几字。
老夫送人情帮搞交互设计的同学(其實是別的专业的，快毕业了唯一能选的必修课要写代码然而苦手)做做小网站写点 React，对前端和网页沒什么兴趣。
对啊实在太过于生草了
第一次看到 human-readable output 的使用场景
作者在这解释了又开新坑的原因：oni2/MOTIVATION.md at master · onivim/oni2 · GitHub
Oni2 项目描绘的愿景很诱人，但具体到实现又充满挑战，有大量的工作要做。
上游也在开放 api，给 ui 更多权限：NVIM v0.4.0 · neovim/neovim@e2cc5fe · GitHub
然而oni2已经准备抛弃neovim自立门户了
基于进程间通信的前后端分离架构看起来很爽，最终还是会遇到各种各样的bottleneck。unix哲学罪孽深重
这也是我不喜欢xi editor的原因
额。。。libvim 上游依然是 neovim，怎么可能“抛弃”呢？它是专为 oni2 定制的瘦身版，某种程度上和 neovim 团队所做的部分工作重叠。
之前 neovim GUI 的开发痛点之一，就是无法满足高度定制的需要。比如 GUI 想自己绘制 minimap、平滑滚动、状态栏、补全菜单等等，会发现和 neovim 本身功能冲突。
neovim 团队正逐渐将 tui/view 层抽离出来，并提供 GUI 相关的事件 API，以解决该问题。只不过 libvim 在这点上做的更加激进罢了。
前后端分离架构，毫无疑问是未来趋势。各种各样的 bottleneck，其实是跨平台开发工具的坑，以及历史遗留问题。
1 个赞
听说过khtml和webkit的故事吗，就算libvim不会反噬nvim，libvim开发者要自己加新功能然后合并不会上游这种事情太常见了
我意思是neovim这种基于字节流进程间通信的方式是野蛮低效的。
纠正一下：刚看了下 libvim，上游是 vim 而非 neovim。
两者不具有可比性，看下关注数就知道。libvim 要解决的是 GUI 开发中 view 层碍手碍脚的问题，除此之外没别的。
前后端分离架构，允许任何语言写的插件与主进程沟通，允许与远程服务器沟通。
还要解决怎么解析VimL的问题
我没说前后端分离架构有问题，我一直在强调nvim那种msgpack传来传去的有问题，你看libvim这个就好多了，直接做成C库，用FFI binding调用不比msgpack强？
所以不同时精通Python，Ruby，Javascript，Lua，C，Rust感觉vim插件都看不懂了，还是emacs适合我等鶸鸡 
突然就感觉X11架构上吊打Wayland了（确信）
用 通用统一 的标准传递数据，这正是该架构设计的妙处。
不用懂多种语言，直接使用就行。如果是开发者，则用精通的语言开发插件。
以上两点，都是 LSP 发展的精髓。