If some people are confused (I was for a long time):
- OCaml is a functional, object-oriented and statically typed programming language that compiles to binaries and bytecode. It's a ML (Meta Language) descendant, like SML for example
- js_of_ocaml is a compiler that takes in OCaml bytecode and outputs JavaScript
- BuckleScript is a compiler that takes OCaml code and outputs JavaScript
- ReasonML is an alternative syntax for OCaml. ReasonML code can be compiled to binaries like regular OCaml code.
- BuckleScript and ReasonML were used together often
- ReScript is a new language that's based on the OCaml compiler, BuckleScript, and ReasonML syntax. ReScript targets only JavaScript and has a
I've been following their progress from a distance and for a while I really believed it would explode in popularity, but the whole renaming things a thousand times over and splitting the project in confusing ways pretty much killed them. And now the introduction page won't even mention OCaml. Why do they seem to make it a point to hide the fact that the language is an OCaml derivative? Do they perhaps believe this is going to make the language more popular? Because I think it will have the opposite effect (it will be easier to dismiss it as "weirder underground TypeScript").
I really wish them success (I'd LOVE to live in a parallel universe where this is the default web language), but it seems like whoever is responsible for attracting developer mindshare is completely clueless.
Disclaimer: wrote this on phone and writing from memory
From how I understand this, ReasonML was/is the true OCaml derivative in JS world.
Whereas Rescript, which was called BuckleScript I think, took the nice pattern matching bits along with the type system from OCaml and married it into JS syntax.
That said, they’ve further tweaked the syntax from BuckleScript days presumably and removed support for JS classes.
We tried ReScript 2 years ago at work when it was still in its infancy, and still named ReasonML. Besides many other gripes at the time, one of the biggest pain points was the lack of any async/await support, and a very cumbersome Promise wrapper.
Unfortunately, it looks like not much has changed[0], and you’re still forced into writing the equivalent of unwieldy Promise chains.
I ended up migrating us onto Typescript, which was a great move for us. The seamless interop with JavaScript combined with the massively active community makes it a no-brainer over other attempts at strongly-typed JS, IMO.
I find it very confusing why they don't embrace the JavaScript echo system. I'm all for a new syntax that does away with some of the bad parts but if you can't async/await, well then you can't really do I/O, and if you can't do that then your app isn't particular fun to use.
That said, I get that there's callbacks for everything and that you can do I/O with callbacks but it's not fun and if that is your only option you're going to need some external Flux "store" to manage all your state.
Edit: I should also add that I understand that there are people who find the async/await paradigm to be bad but I don't think we have much of an alternative when it comes to JavaScript or if you want an alternative, we'll then you are hardcore enough to be fine with just callbacks.
Can’t fully recall the landscape of things back then, but I think you’re right.
I remember needing to navigate between BuckleScript and ReasonML docs (which were terrible at the time) to make sense of the available standard library.
They are in dire need of a RESF. There is precious little current material on youtube about the language and it seems to have sunk into obscurity which is making me hesitant to pick it over TS.
I think they've done a good job of addressing all the initial confusion. I think I get it now.
I'm interested in porting my current sideproject over. Does anyone with experience know how interop might work with a hooks library like react-aria[1]?
"simpler and faster" is not enough, as the key to beat TS is interop with existing ecosystem.
You can have a "simpler" type system yet still end up with an overall less convenient DX. As for "faster", really who cares. I feel that these people in big tech who comes up with these stuff, with their massive codebases, have different pain points to most of us.
The fact that they spent the last how many years changing syntax around doesn't give a good impression on priority either. To be fair, this whole thing started as an OCAML syntax, which is a questionable motivation in the first place.
I have been using Rescript for a project and I really like it. It feels really familiar and I just love the pattern matching with the Option and Result types. It makes error handling really easy.
But you are right, using JS/TS libraries is a huge pain point. It really needs a binding generator for typescript files.
Not having async/await wasn't such a big deal for me.
Readit News
- OCaml is a functional, object-oriented and statically typed programming language that compiles to binaries and bytecode. It's a ML (Meta Language) descendant, like SML for example
- js_of_ocaml is a compiler that takes in OCaml bytecode and outputs JavaScript
- BuckleScript is a compiler that takes OCaml code and outputs JavaScript
- ReasonML is an alternative syntax for OCaml. ReasonML code can be compiled to binaries like regular OCaml code.
- BuckleScript and ReasonML were used together often
- ReScript is a new language that's based on the OCaml compiler, BuckleScript, and ReasonML syntax. ReScript targets only JavaScript and has a
A post on the history of ReScript/BuckleScript in the OCaml forum: https://discuss.ocaml.org/t/a-short-history-of-rescript-buck...
I really wish them success (I'd LOVE to live in a parallel universe where this is the default web language), but it seems like whoever is responsible for attracting developer mindshare is completely clueless.
From how I understand this, ReasonML was/is the true OCaml derivative in JS world.
Whereas Rescript, which was called BuckleScript I think, took the nice pattern matching bits along with the type system from OCaml and married it into JS syntax.
That said, they’ve further tweaked the syntax from BuckleScript days presumably and removed support for JS classes.
Unfortunately, it looks like not much has changed[0], and you’re still forced into writing the equivalent of unwieldy Promise chains.
I ended up migrating us onto Typescript, which was a great move for us. The seamless interop with JavaScript combined with the massively active community makes it a no-brainer over other attempts at strongly-typed JS, IMO.
[0] https://rescript-lang.org/docs/manual/latest/promise
That said, I get that there's callbacks for everything and that you can do I/O with callbacks but it's not fun and if that is your only option you're going to need some external Flux "store" to manage all your state.
Edit: I should also add that I understand that there are people who find the async/await paradigm to be bad but I don't think we have much of an alternative when it comes to JavaScript or if you want an alternative, we'll then you are hardcore enough to be fine with just callbacks.
I remember needing to navigate between BuckleScript and ReasonML docs (which were terrible at the time) to make sense of the available standard library.
I'm interested in porting my current sideproject over. Does anyone with experience know how interop might work with a hooks library like react-aria[1]?
[1] https://react-spectrum.adobe.com/react-aria/
https://forum.rescript-lang.org/
You can have a "simpler" type system yet still end up with an overall less convenient DX. As for "faster", really who cares. I feel that these people in big tech who comes up with these stuff, with their massive codebases, have different pain points to most of us.
The fact that they spent the last how many years changing syntax around doesn't give a good impression on priority either. To be fair, this whole thing started as an OCAML syntax, which is a questionable motivation in the first place.
But you are right, using JS/TS libraries is a huge pain point. It really needs a binding generator for typescript files.
Not having async/await wasn't such a big deal for me.