BuckleScript Is Rebranding | Hacker News Reader

BuckleScript Is Rebranding

reasonml.org

103 pointsyawaramin71 comments

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?

[1]: https://ocsigen.org/js_of_ocaml/3.7.0/manual/overview [2]: https://rescript-lang.org/docs/manual/latest/introduction

I, too, am even more confused than when this rebrand was announced.

Pretty confused over here as well, and I already had a decent idea of the differences and why's between Bucklescript, Reason, and OCaml.

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.

https://rescript-lang.org/docs/manual/latest/introduction

So you're saying their ecosystem supports other languages too?

No, that's not what it's saying...

Then that needs to be clearer as to what it means.

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.

Yep! This talk captures it pretty darn well: https://www.youtube.com/watch?v=Up7LcbGZFuo

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.

The lack of documentation is the main issue that I had with it.

I haven't looked at Reason in awhile, but since its just sugar on top of OCaml, most OCaml docs/stackoverflow questions should help.

It gets tougher when you want to use ReasonReact

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

Yes, the naming is a complete cluster fuck.

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.

BuckleScript (now ReScript, I guess) can still compile standard OCaml syntax.

AFAIK it's a forked compiler and already a number of language versions behind the mainline one.

Yes but OCaml 4.06 is still OCaml.

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.

Yeah, and js_of_ocaml seems like a more reliable solution, since it uses the normal OCaml compiler and just translates the bytecode.

I don't see any reason good React integration couldn't have been built on top of js_of_ocaml.

The whole BuckleScript/Reason project seems like it just made the whole ecosystem messier for very little gain.

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?

> 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.

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.

All these questions are exactly why they rebrand under a single name, ReScript.

- ReasonML is a thin syntactical wrapper on top of OCaml

- To compile it down to Javascript you need Bucklescript, an OCaml-toJS compiler developed by Bloomberg (IIRC)

and so on

All the tools need to be installed from different sites, have their own sets of dependencies and conventions etc.

Not really. ReasonML is vendored and distributed with BuckleScript. It's one install to get started:

    npm install --global bs-platform

They are still completely separate entities when it comes to documentation, library support etc.

Work is done to unify them https://reasonml.org/

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.

Hm. So there was a bucklescript language/syntax - in addition to ocaml and reasonml?

I'm not sure what to make of:

https://rescript-lang.org/

> 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?

Bucklescript extends OCaml syntax. OCaml has good support for language extensions. You need adaptations to interface to js.

OK. So ReasonML and bucklescript both extend ocaml syntax? And the bucklescript syntax and compiler is becoming ReScript - distinct from ReasonML.

But the ReScript compiler supports three syntaxi going forward: ReScript(bucklescript), ReasonML and ocaml?

And the ocaml (native) compiler supports ocaml and reasonml - but not ReScript?

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.

Thank you, that makes things a little more clear for me at least.

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"

Edit: the site is now back

Ooo, that's no good. I'm surprised that wasn't handled better. At least with a simple page explaining what's up.

Or if you go to the docs, BuckleScript is everywhere:

https://reasonml.org/docs/reason-compiler/latest/introductio...

Or if you go to the ReScript docs, the naming has been changed: https://rescript-lang.org/docs/manual/latest/introduction

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 all done directly. No banners needed.

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.

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.

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.

It's use is widening at FB, that's what I understood.

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.

Seems like a poor choice of branding for discoverability and SEO. Really curious about the process for that decision.

"Reason" was/is an inspired name for this kind of programming language. I mean, here's what the dictionary says:

    reason [mass noun] The power of the mind to think, understand, and form judgements logically

Alice: What are you using for that project?

Bob: I'm using Reason

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.

What problems did you have installing? I think it was straightforward for me on manjaro.

This was a year or more ago, but this failed to install: https://aur.archlinux.org/packages/bs-platform/

It's pretty out of date here too. I can't remember if I tried to install with npm.

Oh yes, you definitely want to install it with npm rather than your package manager, unless you are trying to completely avoid npm.

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.

Can I get a compile to js comparison here- if you've used more than 1

1) bucklescript 2) typescript 3) f# fable 4) scala.js 5) gopher.js 6) clojure 7) elm

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

Still no async/await?

Here is what they are saying on reasonml.chat[0].

[0]: https://reasonml.chat/t/bucklescript-is-rebranding/2460

Just another example why betting on platform languages always wins long term.

How so?

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.

https://discord.com/invite/reasonml to discuss with them directly.

So, no more "BS" ;)

Shame libraries like bs-json bs-css bs-express all exist...

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)

TL;DR - https://rescript-lang.org/

Future of BuckleScript and Reason now both called ReScript.

No, apparently not. (it's what I thought first too).

It would seem bucklescript (the language/syntax) and bucklescript (the compiler) and the infrastructure for js interop will be named ReScript.

ReasonML (the syntax/language) will continue to work with both the ReScript compiler/framework and with the ocaml compiler.

Reply on news.ycombinator.com