hongbo_zhang

Yes. Moonbit is heavily influenced by BuckleScript/ReScript. We learned a lot from our previous experience, that's why we are shipping our IDE even in the pre-alpha release. We also learned to how to make type checking fast and parallelisable.

Hi, I am the lead of this project, you can try it now with our online IDE, https://try.moonbitlang.com (F5 to run)

The docs are available https://github.com/moonbitlang/moonbit-docs, the compiler would be publicly available when we reach the beta status (expected to be the end of Q2 in 2024).

Feel free to ask me any question

Hi,some minor corrections.

ReScript is more correct than scala, ReScript's type system(essentially borrowed from OCaml) is sound while scala is unsound.

> Using `undefined` to represent `None` means that you cannot tell the difference between `None` and `Some(None)`

I don't know where you get the impression, of course they are different in ReScript.

One thing missed is that ReScript compiler may be 10-100 times faster than Scala.js (I am not kidding)

Hi, the author of BuckleScript here. JSOO and BuckleScript has very different goals, the former focuses on the compatibility with native, while the latter focuses on the interop and optimal perf on JS backend. The progress of BuckleScript is actually much faster this year if you follow the development closely. OCaml as a language which has been developed for more than 20 years is quite usable without using the latest version, our top priority is to make js interop the best, it is not to catch up the lastest release (but we do have plans to sync up once every two years).

This is ugly

Not really. You can model complex js data type as abstract type, and only provide functions needed

Hi, the main author of BuckleScript here, below is a simple comparison with TypeScript (it may be biased):

- Pros of TypeScript

  - Designed for JS, easy inter-operate with JS
  - A much larger community
  - Nice integration with VSCode

- Cons of TypeScript

  - Compiler slow (not scalable for FB/Google scale)
  - Verbose, very limited type inference
  - Start up time slow (very hard to build traditional build tools)
  - Types are only used for tooling - soundness is not the design goal, not very reliable
  - Only JS backend, no code optimizations

- Pros of BuckleScript

  - No legacy of JS (clean slate) while great story in inter-operation
  - Compiles much faster, scales much better
    10% perf is a nice enhancement, 10x faster is an invaluable feature
  - An arguably much better language
  - Sound type system, global type inference
  - Types are used in code optimization, optimizing compiler
  - Javascript backend + Native backend for X86, ARM

- Cons of BuckleScript

  - Smaller community
  - Learning curve is higher compared with TypeScript

Indeed, fable is a very neat project, but to be honest, it is not as mature as BuckleScript at this time.

For example, it takes around 20~80ms to compile a single file for BuckleScript, while Fable would talk 10x more to compile.

Its generated code is pretty but its performance is not very good, see this issue (https://github.com/fable-compiler/Fable/issues/646) "this can make a difference in speed of up to about six or seven times for tight loop code using tuples, records, lists, unions, etc.(compared with BuckleScript)"

But Fable is a nice project, JavaScript platform is large enough to have both :-)

For web developers who are looking for an industrial strength functional language instead of JS, OCaml probably has the best story here.

Actually it has two OCaml->JS compilers of very high quality The first one, js_of_ocaml, could bootstrap the whole compiler several years ago(probably the first one there).

The recent one, https://github.com/bloomberg/bucklescript, push the JS compilation into next level, it generates fairly readable code, good FFI story, and its compilation is extremely fast, check out the compiler in JS version(http://bloomberg.github.io/bucklescript/js-demo/), and imagine how fast it would be for the compiler in native version. BuckleScript has a good story for Windows, and generates fairly efficient code, see benchmark here: https://github.com/neonsquare/bucklescript-benchmark BuckleScript is already used in production by big companies: for example Facebook messenger.com 25% is powered by BuckleScript, the new WebAssembly spec interpreter by Google is also partly cross compiled into JS by BuckleScript.

Disclaimer: I am one of the authors of BuckleScript

Yes, we implement the whole language, except a very few places that is hard to due to the limitation of JS runtime.

Exactly, client side/ server side in a single language. People are working on porting the Elm architecture to BuckleScript, they will be coming soon

Unlike scalajs, bucklescript maps one OCaml module to one Js module, it is like coffecscript/typescript compilation model, there is no tax on the code size. You can write very clean code, here is an example of avl tree in ocaml compiled into JS(http://bloomberg.github.io/bucklescript/js-demo/#Balanced_tr...)

It is very cool to see different type safe Alt-JS compared, I made a gist here which includes Elm, PureScript, BuckleScript and ClojureScript, add your favorite one here: https://gist.github.com/bobzhang/9f27a5a0bd730e8d3503bf5d058...

`-safe-string` is the future. Any compiler can not guarantee its correctness if you write crazy code , `Obj.magic` here. I am not interested in core personally, but I don't see any reason why it will not work if it is vanilla OCaml

to be precise, Js_of_ocaml does not respect OCaml memory model either, think about float. But I think Js_of_ocaml is really great, BuckleScript and Js_of_ocaml have different use cases.

If you like Elm, you will like Buckle too! we have a much faster compiler, and you can compile it into native code as a bonus : )

Thanks! I have some experience in ocaml compiler internals, I reimplemented camlp4 called Fan. Yes, I made a prototype in 2 weekends and showed it to my boss and got very good feedback

OCaml compiler is designed in an extremely modular style. Actually you can design any syntax for OCaml (including lisp style) and produce the OCaml data structure, then it should work with BuckleScript, that's how Reason works

yes, we will have this warning when upgraded into OCaml 4.04 Note that optimizing mutual recursive call is a very hard problem it needs VM level support

yes, it has a conflict with existing project, so it was renamed later

Definitely, almost half the time is spent in polishing the FFI. Check out the FFI section in the Manual. OCaml's type system is so powerful, that it can model most js libraries without writing JS stubs code

as long as it is vanilla OCaml (no c stubs), it should be fine

you should checkout reason, they are working on bindings using bucklescript. So it is not a dream, people probably can write react app using ocaml very soon

yes, it is actually easier to optimize since you have more herusitics. both compiled to js, so yes, it can work together : )

btw, we also have native uncurried calling convention support to make callback even more efficient

it is generate more readable JS. and we have spent lots of time in polishing the FFI to make OCaml/JS interaction easier

we have an intern this summer create bindings for our internal JS stack. we have some internal stuff running on server side in OCaml which we wish to move to client side. I would say many thanks to my boss and employer's great support

we still reuse ocaml's compiler tool chain. we are compiling ocaml's lambda into JS. so yes, we will support modular implicit once it is landed

I am one of the authors of BuckleScript, you can try BuckleScript in the browser: http://bloomberg.github.io/bucklescript/js-demo/

Click Examples see how the JS code generated, questions are welcome!