5 ms·

ReasonML has more potential. Aside from its excellent type system (one of the best), it can also compile to native code. This has several benefits: - Frontend:

ReasonML has more potential. Aside from its excellent type system (one of the best), it can also compile to native code. This has several benefits: - Frontend: Your tools are fast. The ReasonML-to-JS compiler is already an order of magnitude faster that TypeScript, etc. Fastpack is a native bundler in the works that aims to bundle your project in under a second (and faster for incremental builds). - Mobile & Desktop: Some are experimenting right now with writing a version of React in pure Reason that compiles to native code, bypassing the JavaScript runtime entirely. - Backend: You'll be able to use the Node.js ecosystem but compile certain modules to native code when you need critical performance. Edit: I should add, the Node.js backend story is currently the least developed part of the ecosystem (I'm personally working on getting that up to speed).

amenod 8y ago
Thanks (to the others too), that does sound good.
komuW 8y ago
This reminds me that all those points would apply to dartlang
- cookiecavekeep 8y ago
  Except for the speed argument. For AngularDart projects: the current compiler (ddc) takes minutes to warm up and since it keeps all assets in memory, is quite memory hungry as well. The new incremental build tools are much nicer to use (store assets on disk), and a lot faster after the first build, but still nowhere near sub-second.
christophilus 8y ago
Yeah. The OCaml compiler is just crazy fast. It's like Go, but with a super nice functional language. The compiler seems to be doing a heck of a lot of heavy-lifting in such a small amount of time. I'd be interested in a talk about how it manages that, if anyone knows of one.
- Aeolus98 8y ago
  A lot of the tooling speed comes from a couple places: 1. The compiler optimizations being applied to code - Things like GADT's are able to be allocated very efficiently - Can generate code that doesn't box at runtime (smash it into a pointer is done as well) - Pointers are word-aligned 2. The OCaml runtime - No JIT - No warmup - Can emit native code 3. The HM type system - Typecheckers for HM are really simple [1] [1] https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system#Algorithm_W https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy... This simplicity + the features of the compiler combine to make the OCaml compiler very fast, and very easy to write one (some undergrad CS classes do), and developer-time tenable to make both happen.
BLanen 8y ago
I mean, why even use node for the backend?

amenod 8y ago

Thanks (to the others too), that does sound good.

komuW 8y ago

This reminds me that all those points would apply to dartlang

cookiecavekeep 8y ago
Except for the speed argument. For AngularDart projects: the current compiler (ddc) takes minutes to warm up and since it keeps all assets in memory, is quite memory hungry as well. The new incremental build tools are much nicer to use (store assets on disk), and a lot faster after the first build, but still nowhere near sub-second.

christophilus 8y ago

Yeah. The OCaml compiler is just crazy fast. It's like Go, but with a super nice functional language. The compiler seems to be doing a heck of a lot of heavy-lifting in such a small amount of time. I'd be interested in a talk about how it manages that, if anyone knows of one.

Aeolus98 8y ago
A lot of the tooling speed comes from a couple places: 1. The compiler optimizations being applied to code - Things like GADT's are able to be allocated very efficiently - Can generate code that doesn't box at runtime (smash it into a pointer is done as well) - Pointers are word-aligned 2. The OCaml runtime - No JIT - No warmup - Can emit native code 3. The HM type system - Typecheckers for HM are really simple [1] [1] https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system#Algorithm_W https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy... This simplicity + the features of the compiler combine to make the OCaml compiler very fast, and very easy to write one (some undergrad CS classes do), and developer-time tenable to make both happen.

BLanen 8y ago

I mean, why even use node for the backend?