Hi! I noticed that rescript, despite being relatively young, is already at version 9. According to the roadmap, there are 2 major versions planned for every year, and every even version number is supported for 1 year.
This sounds very odd to me. It’s not a big problem for a tool such as NodeJS to publish major versions frequently, but it’s very uncommon for a programming language. According to semantic versioning, a major version indicates breaking changes, which should be avoided in a programming language when possible.
Anecdotal evidence: PHP released version 4 in 2000, version 5 in 2005, skipped version 6, released version 7 in 2015 and version 8 in 2020. That’s only 3 new major versions in the last 20 years. Python 2 was released in 2000, Python 3 landed in 2008, but Python 2 was officially supported until 2020. And Rust, which is currently at version 1.53, is committed to never release a version 2. Java releases major versions quite frequently, but that’s not a good role model I think: A lost of Java developers are still stuck with Java 8 or even Java 6, which is now 15 years old.
I understand that Rescript originated as a ReasonML->JS crosscompiler called Bucklescript and re-branded only recently, which explains why major version bumps were done more deliberately in the past. But now that rescript presents itself as an independent programming language, you should be careful to introduce breaking changes in the language as rarely as possible. No company is willing to invest in a language, if the code base has to be completely refactored once or twice every year.
If you currently aren’t following semantic versioning, please consider it! It makes it soooo much easier to understand how a new version impacts the users of the language.
To minimize breaking changes, I think that Rust’s edition system deserves a look. This blog post provides a good explanation how it works.
Hi @Aloso, your concern is valid and thanks for bringing it up.
But now that rescript presents itself as an independent programming language, you should be careful to introduce breaking changes in the language as rarely as possible.
Totally agree.
Note the roadmap is one version a year not twice a year. Major version does not mean we break things recklessly, it gives us some flexibility to tidy up things, but it does not mean we will break things because it is a major version.
The things we plan to break is mostly remove the legacy of Reason/OCaml’s stdlib, the major focus of ReScript development is its performance and quality of life improvement.
If you stick to ReScript itself, I don’t think you will have trouble upgrading.
Some minor corrections:
Rescript originated as a ReasonML->JS crosscompiler called Bucklescript
BuckleScript predated ReasonML. ReasonML is a very small part in the ReScript toolchain from the technical point of view. It was originally brought in by Cheng as a pull request and updated by contributors.
It is that we did a favor to support the Reason syntax not that we forked it.
Later we found that ReasonML syntax is not aligned with our vision and we did not have any influence over it.
We could make a fork but we are not interested in doing that with due respect, so we decided to not upgrade it any more and plan to remove it in the future.
Then it doesn’t follow semantic versioning. My point is that it should follow semantic versioning, because is a well defined, well known version system that allows users to see quickly which versions introduce breaking changes. If you don’t follow semver, many people will be under the wrong impression that rescript breaks frequently. This might convince people that they shouldn’t use rescript.
If I’m not seeing things, there’s both an even and an odd version number every year. If you followed semver, this would mean two releases with breaking changes every year.
An alternative would be to only deprecate the legacy parts (with an option to silence deprecation warnings) and remove deprecated APIs later, all at once. This minimizes the number of releases which include breaking changes.
This is reassuring. However, I think it would be even better if this was stated somewhere on the website, and it should be clarified which parts are “ReScript itself” and which parts are likely to change or get removed. People (especially companies) need planning security when adopting a new technology. If they don’t know if their code will be outdated in a year and requires refactoring, they’re unlikely to adopt the technology. That’s why a promise such as “this major version will be supported for at least 5 years” or “there won’t be a new major version ever” is very appealing.