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
5 Likes
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.
1 Like
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.
6 Likes
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.
1 Like
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.
9 Likes
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?).
Hi,
- 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.
8 Likes
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.
1 Like