我是 BuckleScript 作者, BuckleScript 是ReasonML的核心组成部分, 大概率上是国内目前唯一的个人–其所制作的编译器在世界范围内有影响力的了。之前是OCaml编译器的核心开发人员。
希望能多些交流 能够认识到更多朋友
Edit: 问题讲先收集好 明天一起回答 谢谢
我是 BuckleScript 作者, BuckleScript 是ReasonML的核心组成部分, 大概率上是国内目前唯一的个人–其所制作的编译器在世界范围内有影响力的了。之前是OCaml编译器的核心开发人员。
希望能多些交流 能够认识到更多朋友
Edit: 问题讲先收集好 明天一起回答 谢谢
哈哈 bob 好,我来凑个热闹。
About “BuckleScript as its own language”
我昨天跟 Tom 聊了一下我们都觉得 Reason 现在写起来有点太 BuckleScript-ish 了,
bs 的 attribute 读起来有点太像 compiler directives 而不是 language primitive。作为 BS 的作者,你会介意 Reason 把 bs attribute 隐藏起来吗?(这样可能会降低 BS 的曝光)
我跟 Cheng 抱怨后他提了一个 proposal 是做成 decorator 的 syntax 来降低 [@bs] 的 noise,但我觉得还可以再做得更 极致一些,比如我们可以做得跟 Fable 一样直接把 js-interop 做成一个 module?或者做成 first-class syntax (但是这样会有 compile 到 native 时不兼容的问题)
这样学习成本会低很多(其实是我自己头疼,但我觉得别人可能也头疼
btw Cheng 每天都超感谢 buckleScript 和你得
再 high-level 一点的几个问题:
About “the future of ReasonML”
你觉得 ReasonML 对 JSer 来说最难接受的是什么?
你觉得 ReasonML 想要在国际/中国上流行目前最大的困难是什么?
Do we have any idea/roadmap to solve this?
About “BuckleScript as a compiler”:
BuckleScript 主要做了哪些优化?(可以让大家了解一下 BuckleScript 多吊……)
e.g. Constant Propagation/Folding; Dead Code Elimination; Function Inlining…
BuckleScript 目前有哪些瓶颈?
可以是生态上的也可以是技术上的,比如目前优化的 boundary 在哪 (whole-program?)
对想要贡献 BuckleScript 的人有什么建议?(需要怎样的 prerequisite?)
BuckleScript 是对 OCaml 的 Fork…想必要贡献起来应该很难………………
https://bucklescript.github.io/docs/en/compiler-architecture-principles.html
这么多 IR/Pass 太吓人了
About our actual/potential competitor:
如何评价各个竞品?
*Flow (Most-used JS Type Checker)
*Prepack (so-called “bundle optimizer”, sort-of “partial evaluator”)
*Fable (F# to JS compiler)
TypeScript (so-called “superset of ECMAScript”)
Elm/ClojureScript/PureScript (Other FP2JS lang)
Rust (???)
Others (idk)
Hongbo 你好,想请问一下,如果我要使用 ReasonML / BuckleScript,并且用了很多非 ReasonML / BuckleScript 写的第三方 js 库,是不是需要自己写 external?现在社区有小伙伴在补充第三方常用库的 external 吗?覆盖面大概有多少?个人觉得在转型使用 ReasonML / BuckleScript 的过程中,最大的阻碍就是有很多第三方库都要自己写 external,对这个问题官方有什么建议吗?谢谢!
我在 Twitter 上看 Reason Conf 发了不少消息, 而且 Schedule 里的话题看上去很有意思. 想听一下 bob 去参加 Reason Conf 有哪些收获?
bs 的 attribute 读起来有点太像 compiler directives 而不是 language primitive。作为 BS 的作者,你会介意 Reason 把 bs attribute 隐藏起来吗?(这样可能会降低 BS 的曝光)
我不介意 恰恰相反 我希望reason的语法尽可能像flow 而不需要使用bs 这些annotation.
因为bucklescript不打算修改ocaml的语法 所以我没有这灵活性
最难受的可能还是互操作吧
很多js的library 真的非常非常动态 提供type safe的绑定还是需要很多工作的。
感觉这个只能靠时间来沉淀了 一方面希望能有更多高质量的绑定出现 另一方面希望能有更多的高质量的原生的bucklescript library
BuckleScript 主要做了哪些优化?(可以让大家了解一下 BuckleScript 多吊……)
e.g. Constant Propagation/Folding; Dead Code Elimination; Function Inlining…
一些常用的静态语言的优化都有:像escape analysis, flow inference
BuckleScript 目前有哪些瓶颈?
目前bundler还是delegate到其他工具的 像rollup 或者 google closure compiler
好消息是我们在dev mode很快就不需要依赖任何第三方工具了(比如webpack)
对想要贡献 BuckleScript 的人有什么建议?(需要怎样的 prerequisite?)
BuckleScript 是对 OCaml 的 Fork…想必要贡献起来应该很难………………
https://bucklescript.github.io/docs/en/compiler-architecture-principles.html3
这么多 IR/Pass 太吓人了
确实要贡献核心compiler是需要很多预备知识的 但是贡献可以一步一步深入,
比如先尝试着contribute belt library,然后尝试着贡献它的前端 语法解析这一块, 最后深入到编译器本身
*Flow (Most-used JS Type Checker), TypeScript
这两个当然有着天然更好的js互操作性,但是我个人觉得它们在可以预见的将来
是不能保证type safety的,编译器也不可能做基于类型的优化
*Prepack (so-called “bundle optimizer”, sort-of “partial evaluator”)
这个和我们的工作是正交的
*Fable (F# to JS compiler)
设计初衷和bucklescript是很像的 主要更多取决于执行力和社区成长
Elm/PureScript (Other FP2JS lang)
它是一门新语言, 我觉得使用一门新语言的cost太高了(没有大厂的支持下)
ClojureScript
和js 一样都是动态语言, 我觉得没有必要使用另一门动态语言 成本太高了,当然已有大量clojure library需要在js 平台上跑的情况 另说
Rust (???)
这个没有可比性 很少应用中不需要gc
Hongbo 你好,想请问一下,如果我要使用 ReasonML / BuckleScript,并且用了很多非 ReasonML / BuckleScript 写的第三方 js 库,是不是需要自己写 external?现在社区有小伙伴在补充第三方常用库的 external 吗?覆盖面大概有多少?个人觉得在转型使用 ReasonML / BuckleScript 的过程中,最大的阻碍就是有很多第三方库都要自己写 external,对这个问题官方有什么建议吗?谢谢!
你说的是对的 这个需要社区慢慢沉淀 但是其实很多第三方库 在实际工作中 并不是需要提供很多很全的绑定的 可以只写暂时需要的
请问一下如果要学习制作编译器或者是编译原理的话,大概可以从哪里开始下手。
这个感觉还是工作中需要的情况下 成长比较快 靠兴趣驱动难度比较大,OCaml本身是非常适合写编译器的. 推荐一本书 里面有个难度适中 不错的例子
我在 Twitter 上看 Reason Conf 发了不少消息, 而且 Schedule 里的话题看上去很有意思. 想听一下 bob 去参加 Reason Conf 有哪些收获?
最大的体会是欧洲人对函数式语言的热情超出我的想象 他们很多真的是很纯粹的做自己喜欢做的事情