ReScript will only ship with Reason v3.6 in the future… the only way to use newer Reason version is by installing a newer refmt version yourself (with whatever tools the Reason team provides) and wiring it up in bsconfig.json.
Anyways, we highly advice against that since all our tooling / docs / IDE plugin etc will integrate perfectly with ReScript / Reason v3.6 and we cannot guarantee the same quality of error messages / community support / docs / parser performance for separately installed Reason versions.
You’d practically need to rely on the Reason team / community for ReScript support.
Personal note: For the docs it’s actually pretty hard to provide Reason v3.6 syntax switching for code snippets, since we cannot really automate the translation between both syntax without getting a lot of transformation junk (internal decorators, weird transformations, etc).
Lots of examples are also shortened and just can’t be converted, so we literally have to convert and maintain each ReScript code snippet with a Reason / JS output translation by hand.
This is the only way we can ensure that every codesnippet works the way as intended. For the medium term future we’d like to get rid of that extra work and slowly deprecate the old Reason syntax to make the docs visually less cluttered.
Wouldn’t make sense to keep Reason v3.6 syntax for too long when users hopefully will be using ReScript… or Reason v4 which apparently will look different to v3 as well.
That seems like a good way to kill Reason. The bulk of the potential audience for it was always luring JavaScript developers away from TypeScript, this limits it to a subset of OCaml developers (and probably a very small subset).
If there’s a supported way to link Reason v4 into ReScript I might give that a go, even if it’s weird, but long term I’m now wondering if I should just exit the community completely, instead switch to the less-opinionated and better-supported js_of_ocaml. The more I hear from this change the more it’s starting to sound like Elm.
All I am saying is that there is no plan to vendor any newer Reason versions than the current Reason v3.6 within the ReScript platform package.
Hooking up separately installed Reason versions with ReScript is supported, so it’s just a matter of precompiling refmt to a separate npm package and link it via the bsconfig.json. It’s unfortunate you dislike the new ReScript syntax though (probably bc of the missing infix operators?), but we hope you’ll see the up- and downsides after the big transition phase and that you keep an open mind for maybe migrating in the future eventually.
Sadly there is no one-size-fits-all solution for this kind of stuff without any trade-offs
So even if issues arise, with projects like reason-repacked and the like I think the community is strong enough to handle that.
And sadly, ReScript does not provide the full feature set of ReasonML yet, even if you exclude the object system and redefinable Infix operators. Not to mention the very basic editor support. So the docs need to at least support Reason syntax until you roughly have feature parity with ReasonML and reason-language-server.
OK, as long as it’s supported I’m sure I (or someone else in the community) will handle making refmt available on NPM [edit: ah reason-repacked already exists, nice]. Your earlier advice made it sound like this was more than just not recommended, it wouldn’t be a supported use case in the long term.
It started with the missing infix operators, I still plan to do a post and make a case for why more of those should be allowed, but truth be told we could live without them and planned to try the syntax eventually. However, since the announcement our dislike has extended to other things that will never happen like letop and then today I saw local open syntax is gone as well. We use that quite a lot.
Parts of the ReScript syntax are superb, however they are sadly outweighed by the anti-intellectual approach to key functional programming concepts. My team is comfortable with these (our server is written in Haskell) and had hoped letop would let us leverage them more easily on the client side. OCaml has average but improving support for this style of programming, ReScript’s decision to discourage it and refuse supporting syntax is why we have been comparing it to Elm.
I totally get that, but it’s a problem the ReScript team created for itself. What is upsetting my team is we’ve invested 12 months in a big ReasonML project, we were looking forward to syntax improvements through ReasonML updates and new OCaml features in BuckleScript, but now those have been ripped away in favour of some mostly-unexplained “trust us JavaScript programmers will like this better”. Whether future OCaml features will be incorporated, or dismissed as letop has been, appears to depend on the whims of the team and that’s not a viable strategy for us.
Since February I have been working on a blog post announcing my company’s path into ReasonML (delayed by various coronavirus things) and now that this has all happened I’m not sure whether I want to finish it. We are looking for a stable path forward and a direction for the next 5-10 years of development, while ReasonML+BuckleScript was fairly bleeding edge the backing of the OCaml compiler gave us confidence to invest in it. ReScript is forking the community and we’re not sure where we will land.
We certainly won’t be changing anything in the short term, the project is too dependent on shared data types and other things ReScript makes easy. But the way this transition has been announced, managed and discussed in the last two months does not give us hope for it remaining the best path forward in the future.
I’m two minds about letop. On one hand, it’s not exactly beginner-friendly. I personally still find it had to reason about, but maybe it’s just a matter of practice. It certainly looks cleaner than the infix ops for bind/flatMap.
On the other hand, when asked about async/await for maybe a year or two ago, someone from the then-ReasonML team said: Oh, we don’t know yet, let’s see what the community will come up with. Since then the community (and the OCaml devs) mostly came up with bs-let and letop, and the answer to that, it seems, is: Um, no.
Now, I don’t think that maintainers should always listen to the community. Actually, speaking of Elm, I have tremendous respect for Evan for sticking to his vision. (Of course, Elm has very different design goals from Reason or ReScript, and anyway, his dictatorship is not to everybody’s liking). Maybe monadic let is still not good enough. Maybe the team will come up with something better. But so far the question of async/await, which, I guess, a lot of people coming from JS will ask, is still left unanswered.
I’m not fan of adding language features just because they are fancy or shiny.
IMO monadic let or something like do-notation is not just a fancy feature, though I agree it’s not a beginner friendly feature. Alternatives like nested pattern matchs or nested flatMaps can make the code much more complex instead of using monadic notations. Hopefully we got a great doc platform (rescript-lang.org) I think we can have an advanced section to document such advanced features properly with good examples.
I have just had my first chance to play with letop thanks to reason-repacked and it’s way easier to follow than infix functions. I say this as someone who has been comfortable with infix for years, with the alphanumeric additions ReasonML made I can create let.map and let.bind (we have used map and bind in JS/TS for 7 years). It’s fantastic, as good as I’ve heard about. Converting some of my infix-heavy functions to letop definitely made them better, while producing identical JS, and I can now create let.await which will improve our promise code.
At the end of the day I’m just one member of a team, and we will decide as a team whether we want to tack a less-supported syntax onto the side of ReScript and risk the refmt configuration being removed in 5 years or invest in a language transition. I can tell you we’re so disappointed with what we’ve seen from ReScript syntax that if we do make a transition it’s below OCaml on the list.
It has been stated categorically that ReScript will never have letop. If that attitude changed I’d probably swallow my other objections and embrace it wholeheartedly.
Is getting rid of that junk not something that should be on your plate? I think that if you make the decision to create a completely new syntax, you are asking the enthousiast of the language to switch. You’d better have a great upgrade path (including supporting both in the docs). And I think it is good form for it to be an harmonious ecosystem. This would include having frequent communications on both sides, respect for each other and great interop. If you don’t do that I fear that you don’t tap into the enthousiast and early adopters of reason/ocaml right now, you have to build up a community from scratch, and you might kill Reason as a side-effect.
Well let’s not get our pitchforks out too early. Right now we are all just speculating about what will happen and are as a result probably creating a pretty toxic environment for the rescript team.
I would suggest that we let them continue to work on finishing the rebranding and see what will come after that.
As a side note: I just can’t imagine, that rescript will not have any notion of async/await (and similar) syntax. Maybe it will not be letop and maybe it is not their highest priority right now but I do trust them, that they will come up with something (maybe even better - who knows).
I do have nothing but respect for the rescript team. They have always done an exceptional job with the compiler and I am sure that (if we let them) they will do a similarly good job with the syntax.
I want to emphasize I am one of ReScript biggest fans (and probably one of the largest users). I just see the largest users in a production settings have certain concerns, and I am arguing that these people, even if it’s only a small group now, are very important to cherish. I agree the focus on acquiring new users is perhaps the most important goal, but it’s probably a lot harder if you turn the people who love ReasonML at the moment away. I’ve seen this in multiple communities.
The path to success for ReScript is in community building, it’s not technical (because that is already quite amazing). The chaos and community damage was very preventable. The core team is either very surprised at the reactions (because they only looked at these things from a technical perspective), or deliberately breaking with the current community. Both of them are objectively bad decisions. I am very open to advise the core team here if they are interested to listen.
If you are running a company that invested heavily in ReasonML and Rescript, have people working on it in a company on a full time basis, and are looking to hire more, it’s not great that they probably don’t support the current stable syntax because the core team thinks it’s too much work. The new syntax is still buggy, and unstable without any editor support to speak of. It should be an experiment and the documentation shouldn’t be the primary syntax yet let alone the only syntax in current documentation. How to explain this if you have actual employees working on it?
I just see the largest users in a production settings have certain concerns, and I am arguing that these people, even if it’s only a small group now, are very important to cherish.
I absolutely agree with you on that point!
What I don’t really get though is why you would feel like they are turning you away. I also invested quite a bit into ReasonML (probably not as much as you did - and by the way your work is really appreciated) but I don’t feel turned away.
I mean they do support the current stable syntax and will do so for quite some time and the current reasonml.org docs are in the 3.6 syntax and as I understand aren’t going away. Maybe they are even continued by someone from the ReasonML team.
My problem is, that I don’t get why there would be an urgency to switch right now. But maybe someone could explain that to me
I still see the new syntax as an experiment and write my programs in the 3.6 syntax. The only thing we are not getting out of the box, are the new syntax changes in Reason 4.0 but that (for me) is really not a big deal, as they will be mostly convenience changes. (Please correct me if i am wrong on that)
Nothing I’ve said has been hyperbole, it’s all based on actual statements from the ReScript team.
All we have is this statement, so yes something is going to happen, but as far as I can tell there was never a follow up on let sugar (I know they’re busy but it’s been 2 months). When it comes to the more controversial topics, vague excuses and lack of detail is all I’ve seen from this transition (I left discord months ago so maybe I’m just missing out on important conversations).
I don’t feel any urgency to switch. My concern centres around the commitment to support ReasonMLfor a long time, not permanently. While I understand that far-future commitments are challenging, the impression I’m getting is that one day ReScript will exclusively support ReScript syntax. If that’s true I can’t continue to invest in ReasonML as a core language for my company. I work on 5-10 year maintenance cycles and being faced with the choice of never upgrading beyond the last version with ReasonML support or being forced into the new syntax is not appealing.
I would like to plan a switch to the new syntax. ReScript produces the most appropriate JavaScript output of any AltJS compiler out there and many things about the new syntax make that easier. But I can’t make that commitment given the statements made so far about OCaml features that will not be available.
We are not planning to switch anytime soon, and it’s fine for me personally. But when you google stuff you end up in the rescript docs. I was hoping that there would be some effort into supporting production users the rescript platform, who are not switching in the short term. I also was hoping that they keep first class support for ReasonML for the short term in the compiler, the hands-off approach to Reason support in the compiler while the new syntax is still experimental is concerning from a stability viewpoint. (Especially if you have to take risk and adopt this ecosystem in an organization). If you decide the ecosystem is better with two distinct syntaxes, it’s worth it to invest in tools to cleanly cross compile IMO.
It’s not a huge thing because we can take matters into our own hand and work on a great repacked reason, or even fork Rescript. But it would be really appreciated in the community if the core team would support the Reason syntax (including upgrades) until 95% of the community is using the rescript syntax.
I also have to say that most of my concern is fueled by the people that also seriously adopted the Rescript platform. Given their responses I think we have a problem. For our situation it’s slightly less bad because we have a very small team and are not onboarding new people currently. We also don’t use infix operators or other stuff that is not supported by the new syntax, but we cannot work productively without autocomplete and type inference in the editor. We would love to experiment with some native Reason screens/components in our React-Native app (still not a big problem bc we can still use Reason for the shared syntax OR experiment with a ReScript native at that point).
I’m 100% confident that in the short term ReScript will support ReasonML as much as BuckleScript has for at least another year. Maybe even two or three. That much I am confident about given their public statements so far. I’m still working on a switch to reason-repacked, since ReScript will never move beyond their pre-release 3.6 build from before letop was merged.
And sadly, ReScript does not provide the full feature set of ReasonML yet, even if you exclude the object system and redefinable Infix operators. Not to mention the very basic editor support. So the docs need to at least support Reason syntax until you roughly have feature parity with ReasonML and reason-language-server.
Hi, the new syntax will be mostly on par with ReasonML in expressivity modulo object syntax. The difference is that we want ship features in a polished style.
Take the size for example, reasonml is roughly 10 times larger than the new syntax.
Hi, I am not against let-op operators, it is not landed mostly due to our underlying compiler does not support it, and rush it with a ppx is a leaky abstraction which produces bad error message. We definitely will evaluate it once our underlying type system supports it natively
It has been stated categorically that ReScript will never have letop. If that attitude changed I’d probably swallow my other objections and embrace it wholeheartedly.
See my comments above, we will evaluate let-op once our upstream compiler supports it natively. We would like to integrate features in a polished style.
I would strongly suggest not using reason-repacked in production, that would cause a lot of mess in real world.
As a side note: I just can’t imagine, that rescript will not have any notion of async/await (and similar) syntax. Maybe it will not be letop and maybe it is not their highest priority right now but I do trust them, that they will come up with something (maybe even better - who knows).
Actually I am doing research on async-await on my spare time, we definitely want to improve the user experience in promise world, but we don’t want to rush it, so it may take a long time.
That’s interesting, it’s not what chenglou said (I linked to his fairly strong statement above). My sincere apologies for taking such a hard-line stance and assuming the entire team felt the same way. This gives me a lot of hope.
Where I’m settling after the last few days is that let-op (with alphanumerics) appears to be a high quality alternative to infix operators, much easier to explain and fairly self-documenting, so I’m actually planning to remove as many infix operators as I can in the near future.
I’m still evaluating it, I haven’t had a chance to see what the letop error messages are like yet. Thus far it’s producing identical JavaScript to my infix operators so the evaluation has been positive.
