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.
For people who are confused with the discussion, here’s a summary of my view (one of the major contributors to the rescript compiler):
Current status
For people who ship the Reason syntax using ReScript today in production, they are advised to stick with Reason v3.6 for a while until ReScript’s IDE integration is ready, we will let you known once the new syntax is ready for proper usage, and we will provide a migration path from Reason syntax to ReScript syntax when we are there.
For passionate new ReScript syntax users, feedback is welcome and you are welcome to shape the future of ReScript syntax now. Please note that this doesn’t mean the syntax isn’t production ready, it’s solely the lack of type completion / suggestion in the editor that is currently missing (which arguably is an important part for proper usage).
What’s the future of Reason syntax support in ReScript?
The current version of Reason syntax is quite stable and we strongly suggest you stick with it, you will be in good hands and we will provide tools help you migrate to ReScript syntax once it’s ready.
Will ReScript be a very opinionated language?
No, we will find a good balance here, we will only hide some features when the benefit is huge.
In my opinion, the major difference between ReasonML and ReScript will be mostly in two parts:
Quality. You can already have some initial impression that ReScript is significantly faster than Reason and its binary size is much smaller (10x smaller)
Coherent decision. The new syntax will be owned by the same group of people, so that they can make decisions in a coherent way.
We would like to achieve such goals in exchange for dropping native compatibility.
That is great to hear @Hongbo. I think in that context it would be great to have code snippets in the documentation for both syntaxes for the foreseeable future. And I saw in another thread that that is already happening so that’s great as well.
Why do you think it’s not a good idea to run reason-repacked in prod? If it produces a valid AST there is not much that can go wrong? Or is the Rescript more brittle when it comes to what it accepts? (in principle all code that compiles natively on 4.06 should also work on Rescript I would say?).
The third party refmt configurable option was originally introduced for internal emergency bug fix, it’s only tested for a mono-repo setting.
It’s not easy to get refmt installed separately, that means we may receive bug reports we don’t know how to fix if it comes from third party.
It makes migration to rescript hard.
Our vision is to provide best typed language experience on JS platform, arbitrary hooks does not fit our vision, it is bloated, slower and hard to debug. We want to improve the user experience by owning the whole tool stack, encouraging such hooks defeats the purpose.
I will close this thread now since the original question on “What are Reason’s goals” can not be answered by the ReScript folks. Regarding those other questions, I hope @Hongbo made our intents clear!
To get an official answer for the Reason goals question, please open up a new thread on the ReasonML Discourse.
