I really really want this stack to succeed -- I think it has so much potential. And I've been hoping that some of this confusion would get cleared up.
Unfortunately, after reading this blog post I think I'm even more confused than I was before. Are Reason and Rescript separate projects? It seems like there are now _three_ different syntax options: OCaml, Reason, and ReScript? Even if it's a good change in the long run, the lack of clarity is concerning...
Seems like it may be more stable to just stick with OCaml syntax and js_of_ocaml [1] for now...
Also interesting that OCaml is not mentioned a single time on the new website [2]. I guess they're trying to appeal to JS devs and sell it as a new thing, but seems useful to at least be aware that there's a connection to an established language?
I wasn't confused till I read this comment after reading the ReScript docs:
> ReScript looks like JavaScript, works like JavaScript, works with JavaScript, and outputs to the highest quality of clean, readable and performant JavaScript. The big difference is that ReScript comes with a bulletproof type system, a solid build system, and a couple of extra features that'd make JavaScript users envious.
I lucked into a job writing ReasonML (soon to be ReScript) on a React codebase some time late last year, and I've got to say that so far it has been a career highlight for this engineer. Not only did it scratch my itch for functional programming, but I also got to use one of the best type systems around as well, given how this project lives on top of the OCaml compiler.
That said, there were definitely some rough spots along the way, but I'm hopeful that this re-branding and unification of the infrastructure is a step in the right direction.
I definitely had the same positive experience with using OCaml/Reason at my job as well. There's so much power in being able to accurately represent the data model in the type system.
Besides that, the compiler becomes a partner in coding.
- Refactoring things is no longer something I avoid, because the compiler will point out any unexpected places that interact with a given piece of code.
- I can code for an hour without loading the app, and be reasonably certain that the code I'm writing will be more or less be correct.
Overall, I feel like the compiler does the double-checking and second-guessing that I was always doing in the back of my head, which gives some peace of mind and frees me up to focus on the actual task.
Yeah! I'll code for days without running the app. In OCaml, it's as you say, mostly correct when I actually get around to running it. With PHP/JS, I still have a lot of work ahead of me. With OCaml I feel like I'm thinking much more about the problem and less about the language I'm using.
I get puzzled by how often projects whose ostensible user bases are composed entirely of technical professionals seem to make vast sweeping branding changes on the basis of "simplifying" the "confusing" naming, so that we end up with three(?) different things (a compiler, a language syntax, a new almost-compatible version of the language syntax) with the same name.
Is there really a large audience of programmers capable of writing OCaml but not catching on that "BuckleScript" referred to the compiler? (For that matter, is there really a large audience of programmers capable of writing OCaml but only if the syntax superficially resembles JS? Maybe I'm the one out of sync here...)
Reason/BuckleScript has always been about attracting JS developers to the powerful type system of OCaml. That was the reasoning for the Reason syntax. This, to me, feels like another step in accommodating developers who are coming from outside the OCaml ecosystem. When I was a less experienced developer, and even still sometimes now-a-days, as I approached a new language, the difficulties I often had were more with the tooling surrounding a language rather than the language itself.
As a language ages and evolves, I think it's easier for the authors and contributors to forget what it's like approaching it fresh. Many times documentation is written with an unintended assumption of an understanding of the ecosystem. Coming to the OCaml/Reason/BuckleScript ecosystem could definitely be confusing.
I'm a Clojure/Script programmer, it took me 20+ minutes to figure wtf this even is and I'm still not clear on the mission. Clojure is pretty clear https://clojure.org/about/rationale
Here's what it looks like: a new language for cross platform typed functional programming targeting OCaml (server) and Javascript (browser) ecosystem compatibility, backed by Facebook & marketing to mainstream JS devs
This seems like it is only adding to the confusion. Is only BuckleScript rebranding to ReScript or the entire Reason/BuckleScript eco-system? Also BuckleScript is a memorable name and ReScript is just "meh"...
Edit: The "rescript-lang.org" page is clearer -- it's the entire Reason/BuckleScript world is being rebranded into a single unifying thing. Still confusingly though, they call this the "documentation" site.
Can't all of this be sidestepped and just write standard (non-forked) OCaml and feed its bytecode through Js_of_ocaml https://ocsigen.org/js_of_ocaml/ ?
That might not have the ultimate React integration (guess that's the answer to the question). But on the other hand probably aligns better with the instinct of many developers to reduce (albeit not eliminate) levels of unnecessary layering.
js_of_ocaml and ReScript (BuckleScript) have different goals. js_of_ocaml is optimized for working with existing OCaml libraries. ReScript is optimized for working with the JS ecosystem. That's my understanding at least as someone who has only worked in native OCaml and BuckleScript, but hasn't touched js_of_ocaml.
Agreed, but apparently some people take issue with OCaml syntax so they come up with stuff like this.
From my point of view these are all interesting endeavors to watch from my shovel store, and in 10 years they all be stuck in maintenance projects, porting back to JavaScript.
From an outsider perspective it's still make very little sense.
I thought ReasonML is a language, an alternative to Elm, PureScript, or other FRP-focused compile-to-js languages. When I check projects on GitHub written using ReasonML it says "Reason" as a language name (why is it just Reason, and not ReasonML?). For example, Onivim: https://github.com/onivim/oni2
What's BuckleScript then? How is it related to Reason? If it's related why did it have such a seemingly unrelated name in a first place?
Bucklescript is the ocaml -> JS compiler created within Bloomberg.
Reason is just JS syntax like sugar on top of Ocaml. The creator (of React as well) saw it as a middle ground to bring in the giant JS ecosystem and population which makes some sense.
> What's BuckleScript then? How is it related to Reason? If it's related why did it have such a seemingly unrelated name in a first place?
My understanding, is that confusion is part of why they're rebranding everything to ReScript. The language and compiler are now all ReScript.
I think the reasoning for the difference in naming is likely historical. I'm not sure, but I think BuckleScript came before the Reason syntax was developed. But it's not like BuckleScript has any connection to OCaml, either. So I dunno.
The reasonml.org project had a very strong focus on documenting the BuckleScript + Reason workflow (later on it was a goal to add Reason Native docs).
Now that BuckleScript was rebranded to ReScript, we decided to move and simplify the BuckleScript related docs from reasonml.org to rescript-lang.org
As soon as we migrated all our existing Reason / BuckleScript users over to the new ReScript website (with Reason syntax toggling etc), we will most likely redirect reasonml.org to reasonml.github.io, which will yet again focus on pure ReasonML / Native docs.
More details will follow as we are making further progress.
> This has no impact on the development of the ReasonML language. In contrary, ReasonML can now focus on their goals, as much as we can focus on ours.
Does this mean that ReScript is/will be a language that compiles to js, but not machine code?
And that ReasonML will continue as an ocaml dialect that supports both compiling to machine code (eg for back-end services, native apps) - and to js - using the ReScript compiler? But only interop with ReScript when targeting js?
Reasonml is an alternative syntax for OCaml. From the user's perspective, there is just one language OCaml, with two alternative syntax OCaml or Reason. If you want to interface to Js you need additional annotation for FFI, no matter which syntax you choose. The Reason syntax includes this FFI https://reasonml.github.io/docs/en/external adapted from Bucklescript, while Bucklescript itself is just OCaml plus the annotation and maybe other compiler directives. The Reason syntax also includes support for React which is not part of OCaml. I don't know what goes under the ReScript umbrella.
More specifically, the Reason syntax has JSX: you can use React without JSX in OCaml/BuckleScript and you can use JSX for non-React things in Reason (either BuckleScript or native).
If you search for "bucklescript" on Google, it shows lots of links to https://bucklescript.github.io All of them are now broken. So much for "we'll rename tools in backwards compatible way"
The team took an incredible amount of time to make each link redirect to the correct rescript-lang.org resource.
When it was done, the bucklescript github organization was renamed to rescript-lang, which caused a new github pages population to the edges that caused 404s in different regions. It takes a little bit of time until resources are forwarded correctly within GH.
For us in Europe and SF, it was actually working after we made the changes.
As soon as some community members had broken links, they assumed that the team intentionally didn't care about backwards compat, so someone recreated the BuckleScript github organization with a dummy bucklescript.github.io that made a single redirect to the rescript-lang.org site.
From there on all the carefully curated link forwardings were lost. Ironically this actually broke our backwards compat.
It took us a lot of investigation, contacting github, understanding the technical issues with GH pages until we found a solution to restore the original (working) behavior. People should have waited 1-2 days and everything would have just worked fine.
Well, that was a learning nonetheless. We invested many extra hours to get everything up and running again, but now everything works and it will hopefully continue on doing so.
The fact that naming has been changed shouldn't break people's bookmarks, links from blogs, links from external documentation, search etc. You keep the site around until the current version is truly and fully deprecated, and only then remove it, maybe.
The site is back up though. Next step is to plaster banners on each page directing users to the nee docs.
The redirects are done directly if github supports it. Going by the undeniable fact that bucklescript.github.io was unreachable when the repo was renamed, you will need banners.
I'm glad that this project seems to have some momentum. There was a long time when the ReasonML blog didn't update, and I was afraid the language was dead.
This has been confusing for sure - most of the improvements for the language has been blogged at the Bucklescript website, since the Reason repo was only responsible for the syntax (and syntax has been mostly stable). So there is a ton of momentum hidden from visitors on the Reason site.
Hopefully that issue solved by this rebrand - a language should have a unified website for Syntax, Compiler and Standard Lib, and Blog Updates.
I don't think it's in dispute that the name "Reason" is inspired. "ReScript" is not good for discoverability when we're discussing that in the context of search engines, however.
Cool, I hope this does well. Last I looked at reason/bucklescript I really liked it, but found the barrier for entry pretty high. The bsc compiler wouldn't even install on arch.
I was trying to convince my boss to let me break off a piece of my Node.js program and rewrite it as a separate Ocaml process. Which he thought would take too long.
But then I remembered Reason exists and there is no argument about taking too long anymore because I can incrementally convert one function at a time if I need to.
I hope someone convinces the guy who shows up on Google under Rescript to use another name or something.
What blows my mind about bucklescript is the compiled output is small and readable. Also because "it's just javascript" making it work with other javascript is much easier than with other examples. The compiler is also FAST
That experience is similar to typescript "it's just JS" except that the HM type system feels like MAGIC when you compare it to TS.
When you work with cljs and elm you need to bring in the runtime so the payloads are large. Additionally errors in prod can be opaque as the output is usually minified and barely resembles your original source. I believe there is tooling around this but it is still not the same as regular JS in that regard.
Interop between reasonml and cljs is comparable - typing reasonml can take a bit of getting used to but there are escape hatches and gradual typing to allow you to incrementally type things.
So ELI5:
type system of Elm.
Interop and "impurity" of cljs but immutability encouraged by language
"its just JS" like TypeScript
Haven't used f#, scalajs or gopher
Unfortunately, because there are many many layers of complexity which is not always easy to google or discover it can be hard to get started
Platform languages might not be so shinny as guest languages, but they will stay relevant as long as the platform plays a major role, and might even outgrown the platform into other domains.
Guest languages are always fighting for adopting, require FFI, additional debugging tools, tend to create duplicate libraries for everything ('cause their use must be idiomatic in guest language).
Even when FFI is kind of copy-paste compatible with the platform language, eventually the platform language will introduce concepts that aren't that easy to integrate into guest language, or the shiny features from guest language require funnel interfaces to the host language, or aren't exposed at all, thus increasing the divergence.
Then comes the rebranding, which might introduce uncertainty into the ecosystem regarding its future.
So coming back to the platform languages.
C, JavaScript, Java, C#, PHP, Objective-C, Swift might be not be the best, and they have their warts (how I love to hate C), but at the end of the day they own the platform that made them what they are, and will stay around as long as their platforms are relevant.
ReScript will continue to support existing bucklescript bindings and tools (like ppx). It would be great to align library names with the new brand name though (bs- always sounded weird imo)
Unfortunately, after reading this blog post I think I'm even more confused than I was before. Are Reason and Rescript separate projects? It seems like there are now _three_ different syntax options: OCaml, Reason, and ReScript? Even if it's a good change in the long run, the lack of clarity is concerning...
Seems like it may be more stable to just stick with OCaml syntax and js_of_ocaml [1] for now...
Also interesting that OCaml is not mentioned a single time on the new website [2]. I guess they're trying to appeal to JS devs and sell it as a new thing, but seems useful to at least be aware that there's a connection to an established language?
[1]: https://ocsigen.org/js_of_ocaml/3.7.0/manual/overview [2]: https://rescript-lang.org/docs/manual/latest/introduction