Read on Twitter
Doing software archeology of Reason to create some chronology since 2017. Found this:
This was a comment due to the Reason v3 release in October 27th.
You know what& #39;s interesting there? @_binary_search (the same guy who is now working on the ReScript syntax) has been one of the main contributors to the #Reason syntax back then.
You know what& #39;s interesting there? @_binary_search (the same guy who is now working on the ReScript syntax) has been one of the main contributors to the #Reason syntax back then.
In 2017 lots of JS user feedback influenced the Reason language a lot.
Reason v3 was a major break-off from the ML flavor. Suddenly we had to write parenthesis and comas in function applications instead of `fn a b`.
This was outrageous in some sentiments of the community.
Reason v3 was a major break-off from the ML flavor. Suddenly we had to write parenthesis and comas in function applications instead of `fn a b`.
This was outrageous in some sentiments of the community.
It was also also an interesting thing to see how Reason was able to make extremely complex breaking changes without break any existing codebases while allowing a smooth migration path.
I remember this as one of the smoothest ecosystem upgrade experience i& #39;ve ever witnessed
I remember this as one of the smoothest ecosystem upgrade experience i& #39;ve ever witnessed
To go back to the break-off from ML outrage: The community lost a lot of users. Critical voices said that this will completely wipe out interest because of the "divergence from typical FP languages".
Turned out that was not the case for JS developers. It grew immensely.
Turned out that was not the case for JS developers. It grew immensely.
It grew so much that in 2018 we started ReasonConf to do a 3 day retreat for the Reason / BuckleScript community & core team to onboard as many JS newcomers as possible. It was a blast. We were skeptic if we could even get more than 100 ppl to Vienna (a weird place for this conf)
We were booked out early and ran out of tickets bc of venue space. Never would we have thought to have 166 attendees and the core team as support. Probably the most productive conference I& #39;ve ever had to be honest. BuckleScript & Reason were the same thing for us back then btw
Then there were the dark times that changed the face of the community forever. These were the most heated and most passionate and heartbreaking discussions I& #39;ve ever seen in a OSS community: Pipe-first vs pipe-last and the great Stdlib war.
OCaml met JS. This was the first great collision that the community couldn& #39;t really handle.
JS users want camelCase. OCaml users want snake_case (what an irony).
A stdlib can& #39;t implement both, it needs to decide on one convention. Suddenly we faced leaky abstractions.
JS users want camelCase. OCaml users want snake_case (what an irony).
A stdlib can& #39;t implement both, it needs to decide on one convention. Suddenly we faced leaky abstractions.
So what happened? Well, BuckleScript had a bias for JS (it& #39;s a JS compiler after all) so it went with the camelCase approach.
It also settled another thing that probably would have caused a public execution in the 17th century if everyone would have been there in person.
It also settled another thing that probably would have caused a public execution in the 17th century if everyone would have been there in person.
BuckleScript decided to make every Belt stdlib function t-first. What does that mean? Instead of map(cb, value) which allows currying on the last position (like any other functional programming language).
Instead they went with map(value, cb) and a -> operator
Instead they went with map(value, cb) and a -> operator
This was really the first time were BuckleScript started to do politics inside the Reason community. Suddenly nothing seemed to be so peachy after all.
FP users were outraged and cited multiple resources on JaneStreet and Haskell on how "to solve things properly".
FP users were outraged and cited multiple resources on JaneStreet and Haskell on how "to solve things properly".
Things that ppl don& #39;t know: Core members got legitimately harassed in the background. To a point where insults and non-guided conversations were actually causing sickness and burnout to those who want to bring the project forward.
The whole idea of Reason broke down. Reason wanted to be "an alternative syntax to OCaml". BuckleScript wanted to provide the best JS compilation experience possible, but it needed Reason to force certain conventions that are not "idiomatic OCaml"
Well actually it didn& #39;t break down. Reason kept its promise. BuckleScript and Reason started to do compromises on the expense of its users.
E.g. handling naming collisions and keywords: https://reasonml.org/docs/reason-compiler/latest/handling-js-naming-collisions">https://reasonml.org/docs/reas...
E.g. handling naming collisions and keywords: https://reasonml.org/docs/reason-compiler/latest/handling-js-naming-collisions">https://reasonml.org/docs/reas...
During the same time the Esy (the ocaml / npm-like packager manager) was born. It would allow users to install OCaml projects similarly like npm.
`esy install` and all your OCaml version / deps are managed.
Problem was that BuckleScript doesn& #39;t care about that.
`esy install` and all your OCaml version / deps are managed.
Problem was that BuckleScript doesn& #39;t care about that.
BuckleScript didn& #39;t really benefit from the OCaml package ecosystem. Most opam packages are about native system engineering stuff (not JS).
At that time, BuckleScript was trying to be the best Reason-to-JS compiler possible. It tried to be fast and yield efficient, readable JS
At that time, BuckleScript was trying to be the best Reason-to-JS compiler possible. It tried to be fast and yield efficient, readable JS
Adding support for opam packages would also mean add support for all styles and flavors of OCaml code. It& #39;s hard to estimate how complex bundle sizes will be, many OCaml libs depend on ppxes. Build times would probably suffer.
It would be non trivial to just "add support".
It would be non trivial to just "add support".
At that time BuckleScript also dropped OCaml syntax in its documentation. The focus was solely on the target: Getting JS / Reason users to use a language and compiler that uses the OCaml type system without making them learn OCaml.
