Is rescript damaging Ocaml ecosystem?

[cemerick]

@c-cube

ReScript seemed like a confusing rebranding to me, but now I think it’s clearly a separate language that really has nothing to do with OCaml’s ecosystem.

Indeed, though it took a long time to get to that conclusion given the original announcements and relative silence from the Reason folks (a.k.a. Jordan?).

@c-cube

However I’m still not sure what the future of Reason is: is it maintained? Will it be a valid syntax for native OCaml in 10 years? So in this sense ReScript might throw doubt about the future of Reason.

The only concrete statements around this AFAIK are from Jordan in Discord last August:

It’s true enough today to say that Reason is for native and ReScript is for web, but that would mis-manage peoples’ expectations to state that in docs because that’s not the actual dividing line between the two. ReScript (from what I understand) is more about a unified stack for targeting JavaScript yes and I think that’s a good thing that is much needed. And yes, Reason will target native. But our plans for Reason are to continue investing in Reason as a JavaScript developer friendly, backend agnostic language on OCaml, and OCaml ecosystem. The main dividing line is actually more like whether or not there is support for OCaml conventions such as build system, package management, extended language features. Reason Syntax and related tools such as esy focus on compatibility, with the tradeoffs you’d expect.

Compiling to JS or not is not the most important dividing line. We will also build a toolchain that allows people to compile Reason Syntax + ocaml ecosystem compatible projects to JavaScript based on jsoo with improved integration with JS ecosystem, but for people who don’t have as much of a need for BS’s excellent JavaScript output. This is to make sure people that were working on shared universal codebases are not left hanging. We got you!

…and then this github issue: Future of ReasonML, planned support for the BuckleScript/ReScript compiler · Issue #2634 · reasonml/reason · GitHub

Judge for yourself, I guess

[VPhantom]

@VPhantom

I was under impression that OCaml syntax documentation was removed by choice, but I could be mistaken.

I dug a bit deeper to figure out the source of my confusion on this. Last year, A Note on BuckleScript’s New Syntax and Its Future Support Commitments said:

We won’t remove OCaml and Reason support from BuckleScript for a long time, whatever the surface emphasis might be.

This was good enough for me to keep using the compiler to get its wonderful JS output; I could use the old 8.0 docs site until the new site caught up. There were already multi-language tabs for the code examples. However I see this in ReScript/CONTRIBUTING:

• No references to OCaml . ReScript is its own language, and we don’t rely on external resources of our host language.

Therefore, while the other syntaxes are still supported for now by the compiler, how to use them (especially the numerous extensions for FFI) is explicitly undocumented.

[rgrinberg]

However I’m still not sure what the future of Reason is: is it
maintained? Will it be a valid syntax for native OCaml in 10 years? So
in this sense ReScript might throw doubt about the future of Reason.

That’s right. A much more valid complaint would be that ReScript is damaging the Reason ecosystem. Though I can’t help but find it ironic that a community founded on the ground of “improving” OCaml by changing the syntax is so bothered by a similar effort to improve upon it.

[kanishka]

My best understanding for how to approach the jsoo vs rescript selection for a company with ocaml devs implementing a single page application is as following:

if you have a few months to a year of breathing room to develop libraries from the ground up to work within jsoo world of libraries, then go with jsoo. if you need to deliver your product/startup MVP/project faster than that, you probably have to rely on rescript because it gives you access to every NPM browser js library in existence.

[Kakadu]

@bobzhang

The ReasonML parser alone is as large as ReScript the whole compiler. I

AFAIK, ReScript has rewritten entire parser from YACC-like syntax to manual recursive descent and nothing else. (It could totally remove everything related to OCaml native code generation but I’m not sure). That’s why (on my opinion) it

1. should run slower because LR analyzer compiles to automaton, specialized to the domain of parsing;
2. should has larger code base because YACC-like syntax is a specialized DSL for parsing.

Can you, please, clarify your statement?

[yawaramin]

Reason parser targets a large number of OCaml versions. That causes a combinatorial explosion in size. It’s like a PPX. ReScript parser is manually written to target specifically the ReScript compiler. More hand-written code but tiny binary size.

[mars0i]

The number of cool languages that have come and gone would be difficult to know. Some died quickly, or were never fully alive, and some had several good years but didn’t make it to today. (I’m still fond of SML.)

For a long time, I imagined trying to sell OCaml to other technical people at my university. I always felt that asking people to learn a syntax as unfamiliar as OCaml would make that more difficult. I loved the idea of Reason because of that. I was interested in compiling Reason to native code, which would appeal to the people I had in mind. This was doable in theory, but was clearly not the focus of the Reason community. I felt I had to wait until Reason was less bleeding edge before thinking about selling it to anyone.

There were no books for a while, and there were non-backward compatible syntax changes happening (still before ReScript). I couldn’t tell anyone to use that as a new language to get work done. I would feel responsible if they got tripped up by language changes or have to abandon it and rewrite in a new language.

I know less about what’s been discussed in the OCaml, Reason, ReScript communities than others here do, but I feel that for the moment, Reason has been killed or fragmented by ReScript. (There are several Reason books out now, and I feel bad for the authors and publishers.) Bob Zhang and others can do whatever they think best–there are difficult tradeoffs–and in the end ReScript might become a sufficiently popular, stable language. I feel that for now the amount of churn with Reason/ReScript will, and should, scare a lot of people away. I’m sure the ReScript folks thought about that. It’s a long-term strategy that they are pursuing.

On the other hand, I now think it’s unlikely that OCaml will ever get a more popularly-styled syntax that can be used to introduce it to others. I’ve given up on that.

Maybe that should be considered damage to a possible future for OCaml, but it was only a possible future. Even if it someday became a safe practice to write in Reason for native-code compilation, all of the libraries would still be in the traditional syntax. You could run OCaml library source through a translator to get out Reason-style source, but the documentation would still use OCaml syntax. So maybe using Reason syntax for native-code OCaml would never have been a good way to sell the language.

If I want to sell OCaml to others, I will just have to help people over the (camel’s ) hump of learning the syntax.

[kantian]

@mars0i

For a long time, I imagined trying to sell OCaml to other technical people at my university. I always felt that asking people to learn a syntax as unfamiliar as OCaml would make that more difficult.

[…]

If I want to sell OCaml to others, I will just have to help people over the (camel’s ) hump of learning the syntax.

That’s a very old problem and, to my knowledge, nobody has found a solution. So let me quote, just for fun, this Brief, Incomplete, and Mostly Wrong History of Programming Languages.

1936 - Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.

Unfortunately, this criticism still occurs nowadays.

[Chet_Murthy]

And then along comes Larry Wall to invent a better LISP than any that has come before [Perl 5], and nobody will use it b/c it’s insufficiently LISP-like.

[just carrying on the joke, mang]

[zhtprog]

Reason/bs-platform was a great onboarding tool for Windows users targeting js. For me at least it is not so much the syntax as the one stop installation of the tool chain. OCaml was a pain to install on Windows. Even with WSL the Ubuntu stock opam/ocaml is so old bordering on being useless. I think people tend to over value the usefulness of surface syntax when in this day of age it is very easy to look up code examples in any syntax (so long as you avoid operators ) and with IDEs it is even less an issue. On the other hand if you have a tool chain issue it would be very painful to tackle because there could be so many variations and faced with an issue most new users just give up. I think it is @bobzhang’s dedication to making an amazing js tool chain that drew lots of users to give it a try.

Now I am on a new M1 Mac the experience of using OCaml natively is excellent and I never thought of using anything but the OCaml syntax. It is Unix and the C-bindings that really shape the experience of native development. If I am going to target js again I think I will still choose ReScript just to access @bobzhang’s bs-platform. The importance of sharing code across targets pales in comparison to the ease of accessing native libraries or js libraries well.

[Khady]

From an industrial point of view, rescript (reasonml + bucklescript when we started) allowed us to hire many people that we wouldn’t have attracted otherwise. Those people now also write native ocaml code. Maybe with all the experience and hands we have we would be capable of switching to jsoo. But at the time we could have not built a team around jsoo. So yes there was some drama, yes there are some downsides, yes there are some duplicated efforts, yes some people are hurt. But overhaul it created many opportunities that we are grateful for.

[avsm]

@Danielo_Rodriguez

That’s why I’m here, asking for a different perspective on the topic from people within the community.
I admit that I could have phrased the title of my post better, but thinking about it, I don’t come but much better alternatives that are still short.

You could frame your post with a constructive perspective instead of a damaging one. For example, you could rename it immediately to “How is Rescript helping the OCaml ecosystem?” immediately, and it would come across as less entitled. Think about the impact of your words on the maintainers of these tools who work hard on open sourcing them and supporting them.

From the perspective of the OCaml community as collected by the opam repository of packages, we do not take a position on any of the downstream users of opam. We work hard to make sure that all the communities have their voices heard and their projects distributed (Coq, MirageOS, Ocsigen, Tezos, Jane Street, Reason, BAP, to name just a few off the top of my head). You can browse some of last year’s opam community meeting minutes which have been very useful to help guide the opam roadmap.

Several of these communities (e.g. Coq and Reason) maintain their own ecosystem of domain-specific packages that is separate from the mainline opam-repository, and that is just fine too. Both opam and OCaml have a strong focus on stability and continuity, and this also implies we do not take cyclic links on downstream projects. You just need a C compiler toolchain (with a dash of C++ for some opam solvers) to bootstrap opam and gain access to all of this for years to come.

I can appreciate that for users it can be difficult to figure out a toolchain to pick when there is asymmetry in the levels of communication between OCaml and downstream users, particularly through the OCaml website. This came through loud and clear in the recent user survey (along with a request for better documentation infrastructure), both of which are topics I’m working hard on fixing. See OCaml 2020 for an overview talk I gave on this late last year, and expect an update on 2021 plans for these topics on this forum shortly as I get consensus from many OCaml maintainers involved

[Danielo_Rodriguez]

@avsm

You could frame your post with a constructive perspective instead of a damaging one. For example, you could rename it immediately to “How is Rescript helping the OCaml ecosystem?”

I already admitted that I could have phrased my post better, and I apologized about it, but I don’t mind doing it again.
I appreciate any open source work, despite I like it or not. I just wrote how I was feeling in the title and that is never a good idea.

[carlosdagos]

@Danielo_Rodriguez

This is […] a very small community, which seems to split every few years into smaller and smaller ones.

Just want to point out that this is a feature of many niche communities. If you are getting into a niche language or other tech, you should understand that this comes with the territory.

[kanishka]

There is something unique about the mess with javascript that makes the choice between using a large mainstream project and a niche project more painful: both the build tooling and the language are not really palatable in the mainstream option. Webpack, babel, etc, work, but few people understand them all, and complexity seems to be artificially created, not inherent to the problem. In reaction to this complexity, there is create-react-app, nextjs, etc, to abstract webpack and babel, which hides the problem… The attempts to escape the build tooling and language mess like Elm, jsoo run into size of ecosystem issues.

In the past, when choosing java or an alternative on the server, the build tooling in different options had some issues, but mostly you were choosing based on the difference in language and ecosystem philosophy. One wasn’t necessarily running away from something, more running forward to an ideal.

[pbiggar]

@Kakadu

That’s why (on my opinion) it

1. should run slower because LR analyzer compiles to automaton, specialized to the domain of parsing;
2. should has larger code base because YACC-like syntax is a specialized DSL for parsing.

FYI, parsers written with YACC-like tools tend to be slower and worse (especially with poorer error messages) than hand-written parsers.

[c-cube]

Do you have any source to back that up? In OCaml it’s never been my
experience, menhir generates pretty good code and there’s no
backtracking or lookahead involved. What would make a handwritten parser
faster exacty?

[pbiggar]

I’m not talking about menhir - don’t know anything about it. My source is my history of working on and studying compilers; don’t have any more than that for you. The one that comes to mind is the GCC C++ compiler; though now that I think of it I believe the VC++ compiler has a similar hand-written parser.

My understanding of what makes them faster is that parser generators tend to generate many superfluous states. I’m not an expert in this, so I’m just relaying what I recall.

[silene]

@c-cube

Do you have any source to back that up?

It is pretty circumstantial, but you can look at the history of parsers in GCC. In 2000, they rewrote the C++ table-based parser into a recursive-descent one. The primary reason was to improve the error messages. The secondary reason was to make it easier to follow the evolution of the language. Performances were not a motivation but rather a requirement not to regress. It actually took them several months of work to get on par, performance-wise. (With the experience gained, changing the C parser in 2004 proved to be much easier.)

The tens of language front-ends provided by GCC have now all been converted to recursive descent parsers. There is not a single table-based parser left, as far as I know. And none suffered from a slowdown as a result. Do not except astonishing speed ups, though. The parsers became only a few percents faster in the process. (But anyway, speed was never the motivation in the first place.)

And just to be clear, getting rid of table-based parsers in GCC was never a political decision. It just happened organically as time passed, in order to improve error messages in every front-end.

[c-cube]

Sqlite, arguably a pretty fast C program, uses lemon to parse its input.