New ReasonML syntax - Githubissues

I just discovered today that the lastest version of BuckleScript, landed with a new (optional) syntax for ReasonML: https://reasonml.org/blog/bucklescript-8-1-new-syntax

From what I could see, many features would be removed (permanently or not, that's an other story). Things like custom operators, ~or even first class modules~ (edit: this one is still supported by the new syntax) for instance seem to not be supported at all by the new syntax. It's still unclear whether the above features are dropped by design, or just for a while, and will be added back to the language though.

Do you plan to keep the current API, including the operators, in the future (which might require a complete rewriting in OCaml), or will you embrace the new syntax?

I'm not going to talk for @mlms13 or @andywhite37 but I think the overall idea of Bucklescript as a language is pretty hostile to things like Relude. I think effort would be better spent into making a case for such a thing to not happen than to try and shoehorn Relude into such an environment.

I doubt we'll embrace the new syntax. I honestly don't know what the future holds for this project, and people like Cheng Lou have made it clear that they want to dumb down the language to the point where it's no longer compatible with some of the abstractions and ideas we all know and love. I think they are making closed door, ill-advised decisions about the direction of the language without consulting anyone, and saying things like "we don't want to do functors/applicatives/monads." Not sure who "we" is, but I would suggest for people to think hard about this ecosystem as it's likely to start fragmenting even more, and BuckleScript-based Reason is moving away from anything that sounds remotely like traditional FP. The leadership is completely dismissive of the ideas that we all know are incredibly valuable, so I'm over it. My gut sense is that if you want to continue doing Reason/Ocaml with FP abstractions, maybe it makes sense to start looking at JSOO rather than BuckleScript, but I'm kind of meh at this point. To be honest, I would love for this whole community to actually move to PureScript, as it truly is what I think many of us want to be doing. Not saying PureScript doesn't have it's own challenges, but I think that's a far more professional, open-minded, and innovative community. Even TypeScript has a much more vibrant and innovate FP community compared to ReasonML.

I'm not trying to start a flame war, but just saying that this library is not in-line with the core values of the BuckleScript-based Reason leadership, so it's not likely to survive if they are intent on killing our ability to do the things we want to do.

To echo the other points already made here, Reason leadership* has been pretty openly dismissive (and at times actively hostile) toward the work we're doing in Relude. While these changes in syntax are frustrating, they aren't particularly surprising (and I wouldn't be the least bit surprised if there are future changes to things like currying and piping).

The change in syntax was done behind closed doors specifically to discourage the kinds of debates and concerns that we're now raising. In the time since the announcement, these concerns have been met with vague responses and dismissive arrogance. Unfortunately, this is exactly the level of professionalism I've come to expect from our leaders. Cheng Lou's "to write PureScript choose PureScript" comment came immediately after I voiced concerns about what these changes mean for Relude.

Obviously this new syntax is the catalyst, but ultimately the underlying issue is that I don't trust Reason's leaders to provide a stable language, build a thriving ecosystem of fp tools, or ultimately be welcoming to those of us who enjoy this style of fp. It's hard to trust leadership that is this unwilling to engage with the great work being done in so many other fp ecosystems. This is, of course, deeply disappointing as I've poured loads of time and energy into this community over the last few years.

I don't want to speak for Andy, but I think I can say with some certainty that we're both committed to maintaining the libraries we've worked on here, at least until the Reason language makes it impossible to do so. But in light of recent events (and less recent ones as well) it's hard to remain upbeat and energetic about the future of this library and ecosystem. I'll second Andy's point that both PureScript and fp-ts are great alternatives that could certainly benefit from an influx of the kinds of people who are still reading, 4 paragraphs in to my long-winded response to a Relude issue. Go support communities that will appreciate you!

* I want to make it clear that when I refer to "Reason", I'm referring to Reason + BuckleScript (not Reason for native/JSOO), and when I refer to "Reason leaders" I don't mean all of them. I had a really great chat with Jordan yesterday, and Bob has consistently be helpful in answering questions and following up on issues (and he's even contributed to Relude!) ...I guess that means I'm referring to the other leaders. :wink:

Thank you all for you answers, it's relieving to read you have plans to support this library as much as possible. Relude is, for me, what OCaml "stdlib" should be at one point, with a different implementation maybe, but with the same extremely convenient functions and operators.

Reason's leaders (as per @mlms13 's definition), have always made clear they planned to change the feature set eventually, mostly the curried nature of OCaml, but I didn't expect such drastic changes, and definitely not now.

A couple of months ago, a pull request got rejected on the BuckleScript repository (https://github.com/BuckleScript/bucklescript/pull/4271) for one (good) reason: the maintainers planned to fix some of the (numerous) issues and bugs on both ReasonML and BuckleScript first. And announcing a complete revamp of the syntax today is "unexpected", to say the least.

I don't trust Reason's leaders to provide a stable language, build a thriving ecosystem of fp tools, or ultimately be welcoming to those of us who enjoy this style of fp.

I totally second you here. We already had some heated debates some years ago when ReasonML's leaders decided to make the language more familiar to JS developers, by including parentheses, or "proper" if/for expressions. It led to a lot of fragmentations (BuckleScript Tea for instance is written in OCaml). But at least the feature set was kept. In the new syntax there is no guarantee that any library, or application built with the current syntax will be compatible with the new syntax. For those of us who dedicated a lot of time and energy to the community, or for some companies who believed in ReasonML and built, or are building, commercial applications with it, it's a disaster.

I won't use ReasonML anymore (to be honest I've always liked the OCaml syntax more, which is unfortunately not really "React-friendly" https://github.com/BuckleScript/bucklescript/issues/4501), but I also think there is a place for BuckleScript and OCaml. One of my main concern is not only that ReasonML, as we know it, disappears, but that many people quit the community, leaving an enormous void... In that regard, it's important to know what BuckleScript's support for OCaml will be in the future.

Cheng Lou's "to write PureScript choose PureScript" comment came immediately after I voiced concerns about what these changes mean for Relude.

This, and the fact the statement completely misses the point. Many members of the BuckleScript community already know PureScript, its strengths, and its weaknesses, but still chose BuckleScript. I love PureScript's syntax, IDE support, type classes, and the solid and consistent libraries built using PureScript, but OCaml's learning curve, practicality, and flexibility (not even mentioning the great FFI support offered by BuckleScript), make it the way to go especially when working in a team with less experimented developers.

This is not the only misconception from the ReasonML leaders, but it's an important one. Same goes for we don't want to do functors/applicatives/monads thing. These concepts are not related to the syntax, and they can still exists after the syntax change. So what's the point with the first class module, custom operators, etc... witch-hunt? Removing the syntax will just make the code more obfuscated for those who like and use these concepts often.

To sum it up, I'm really glad you have plans to support Relude as much as possible, even if the ReasonML's leaders don't like it, and I hope this library can outlive the ReasonML language. OCaml is a great language, filling a void in the FP world, and some of the new features make it even better (provided the last versions of OCaml will be supported by BuckleScript).

This is all disappointing but completely understandable. It's been a bit of a struggle to write a large Bucklescript app (~100k loc via Reason) but Relude has been a great help in building some sane patterns through it all. But at the same time, I constantly going back to thinking it just shouldn't be such a struggle. We're currently trying to figure out exactly how to move forward as well. Either way, I wanted to say thanks to the team for all of your work, it's been really appreciated!

Thanks for the feedback, everyone. @mlms13 Here's some important points to clarify or inform:

The new syntax is currently called "The New BuckleScript Syntax".
The New BuckleScript Syntax does indeed seem to be trimming out some features.
Reason Syntax will continue to cover all of the features of the OCaml language, and will focus on compatibility with the OCaml ecosystem/conventions.
Reason Syntax project will continue to implement the v4 features in the open, as planned. Many of these features bring Reason Syntax closer to the new BuckleScript Syntax (not all the way), but it will take a little longer to get all of them implemented since Reason Syntax has a much larger surface area due to supporting all of OCaml's syntactic features.
Nothing changes for people using Reason Syntax with BuckleScript for quite a while, and the new BuckleScript syntax will be opt in.
If/when something has to change for people using Reason Syntax with BuckleScript, we will make sure that everyone's use cases are covered. There is a (larger than I expected) set of people using Reason with BuckleScript today that have use cases overlapping with ocaml-ecosystem-compatible development. That might be because they are sharing their code base with a native toolchain, or prefer/make heavy use of conventions that are common in the ocaml-compatible-ecosystem. I'll work directly with those people on an alternative workflow is supported that is ocaml-ecosystem-compatible. There's no way to promise it will solve all your problems, but by that point, either the new BuckleScript Syntax will have the things you need or the alternative workflow will likely be much more suitable.
I haven't yet found anyone that makes use of these Reason Syntax /ocaml-ecosystem conventions , that is unsatisfied with the BuckleScript Syntax - and that also would not be a good candidate for the alternative workflow, so that's promising.

Thanks, everyone, for your support and understanding, and thanks especially @jordwalke for clearing some things up.

I think many of us here feel like we bet big on Reason (building tools, libraries, and in some cases companies) under the assumption that Reason is OCaml, and BuckleScript is an OCaml compiler (inheriting both its pragmatism and its deeply academic tradition). The BuckleScript 8.1 announcement, especially as it was originally framed, raised some pretty foundational questions about what this ecosystem is, what it hopes to become, and whether we made a bad bet.

While I still have some concerns -- and a lot of questions -- about what the future of Reason/BuckleScript looks like beyond the short-to-mid term, it's encouraging to know that Reason itself isn't intending to diverge from OCaml's language features, and our use cases will hopefully still be covered. I'm definitely intrigued by this "alternative workflow." 😄

I'm going to close this issue, but I want to reiterate that Andy and I intend to continue supporting Relude as long as the surrounding ecosystem makes it possible to do so. Please keep opening issues and PRs, and feel free to reach out to us, either here on GitHub or elsewhere, with any questions and concerns. My DMs on Twitter are always open, and while I don't plan to be active on the Reason Discord anymore, feel free to add me as a friend there if you ever want to chat about Relude or anything: mulmus#4010.

reazen / relude

New ReasonML syntax #274