我是 Hongbo Zhang, 欢迎来问关于ReasonML/BuckleScript,函数式语言,还有静态类型系统的任何问题

#1

我是 BuckleScript 作者, BuckleScript 是ReasonML的核心组成部分, 大概率上是国内目前唯一的个人–其所制作的编译器在世界范围内有影响力的了。之前是OCaml编译器的核心开发人员。

希望能多些交流 能够认识到更多朋友

Edit: 问题讲先收集好 明天一起回答 谢谢

3 Likes
pinned globally #2
#3

请问是在什么契机下开始接触函数式语言的?

2 Likes
#4

哈哈 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 和你得 :wink:

2 Likes
#5

再 high-level 一点的几个问题:

About “the future of ReasonML”

  1. 你觉得 ReasonML 对 JSer 来说最难接受的是什么?

  2. 你觉得 ReasonML 想要在国际/中国上流行目前最大的困难是什么?

  3. Do we have any idea/roadmap to solve this?

1 Like
#6

About “BuckleScript as a compiler”:

  1. BuckleScript 主要做了哪些优化?(可以让大家了解一下 BuckleScript 多吊……)
    e.g. Constant Propagation/Folding; Dead Code Elimination; Function Inlining…

  2. BuckleScript 目前有哪些瓶颈?
    可以是生态上的也可以是技术上的,比如目前优化的 boundary 在哪 (whole-program?)

  3. 对想要贡献 BuckleScript 的人有什么建议?(需要怎样的 prerequisite?)
    BuckleScript 是对 OCaml 的 Fork…想必要贡献起来应该很难………………
    https://bucklescript.github.io/docs/en/compiler-architecture-principles.html
    这么多 IR/Pass 太吓人了

2 Likes
#7

About our actual/potential competitor:

如何评价各个竞品?

  1. *Flow (Most-used JS Type Checker)

  2. *Prepack (so-called “bundle optimizer”, sort-of “partial evaluator”)

  3. *Fable (F# to JS compiler)

  4. TypeScript (so-called “superset of ECMAScript”)

  5. Elm/ClojureScript/PureScript (Other FP2JS lang)

  6. Rust (???)

  7. Others (idk)

1 Like
#8

ReasonML解决的痛点是什么?

#9

Hongbo 你好,想请问一下,如果我要使用 ReasonML / BuckleScript,并且用了很多非 ReasonML / BuckleScript 写的第三方 js 库,是不是需要自己写 external?现在社区有小伙伴在补充第三方常用库的 external 吗?覆盖面大概有多少?个人觉得在转型使用 ReasonML / BuckleScript 的过程中,最大的阻碍就是有很多第三方库都要自己写 external,对这个问题官方有什么建议吗?谢谢!

1 Like
#10

请问一下如果要学习制作编译器或者是编译原理的话,大概可以从哪里开始下手。

1 Like
#11

我在 Twitter 上看 Reason Conf 发了不少消息, 而且 Schedule 里的话题看上去很有意思. 想听一下 bob 去参加 Reason Conf 有哪些收获?

#12

大三的时候在MSRA实习的时候接触到F#的,那时候觉得好优雅,然后就入了坑。沉默成本越来越高了。。

#13

bs 的 attribute 读起来有点太像 compiler directives 而不是 language primitive。作为 BS 的作者,你会介意 Reason 把 bs attribute 隐藏起来吗?(这样可能会降低 BS 的曝光)

我不介意 恰恰相反 我希望reason的语法尽可能像flow 而不需要使用bs 这些annotation.
因为bucklescript不打算修改ocaml的语法 所以我没有这灵活性

#14

最难受的可能还是互操作吧
很多js的library 真的非常非常动态 提供type safe的绑定还是需要很多工作的。
感觉这个只能靠时间来沉淀了 一方面希望能有更多高质量的绑定出现 另一方面希望能有更多的高质量的原生的bucklescript library

1 Like
#15

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,然后尝试着贡献它的前端 语法解析这一块, 最后深入到编译器本身

1 Like
#16

*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

1 Like
#17
  • 编译速度快
  • 可靠性高 type safe
  • 性能更好 编译器做更多优化
#18

Hongbo 你好,想请问一下,如果我要使用 ReasonML / BuckleScript,并且用了很多非 ReasonML / BuckleScript 写的第三方 js 库,是不是需要自己写 external?现在社区有小伙伴在补充第三方常用库的 external 吗?覆盖面大概有多少?个人觉得在转型使用 ReasonML / BuckleScript 的过程中,最大的阻碍就是有很多第三方库都要自己写 external,对这个问题官方有什么建议吗?谢谢!

你说的是对的 这个需要社区慢慢沉淀 但是其实很多第三方库 在实际工作中 并不是需要提供很多很全的绑定的 可以只写暂时需要的

1 Like
#19

请问一下如果要学习制作编译器或者是编译原理的话,大概可以从哪里开始下手。

这个感觉还是工作中需要的情况下 成长比较快 靠兴趣驱动难度比较大,OCaml本身是非常适合写编译器的. 推荐一本书 里面有个难度适中 不错的例子

1 Like
#20

我在 Twitter 上看 Reason Conf 发了不少消息, 而且 Schedule 里的话题看上去很有意思. 想听一下 bob 去参加 Reason Conf 有哪些收获?

最大的体会是欧洲人对函数式语言的热情超出我的想象 他们很多真的是很纯粹的做自己喜欢做的事情