Some thoughts on community building

1

Note this is my personal thoughts, it does not reflect the team’s opinion.

The rescript compiler has been developed for almost 6 years, and I believe it has been the best amongst those alt-js compilers from the quality point of view, the second does not come close. But from the market point of view, it has a long way to go, so I think there are some thing we need improve on non tech side – community building.

My observation is that in the past few years, we have always been living in the shadow of OCaml community, it is actually not good for our growth (note we acknowledge the value that OCaml brings us and put it on the top of thanks list in the ReadME), I hope as a community we reach a consensus that we adopt ReScript is due to the value that ReScript brings by itself instead of reusing code on native side.

Why stay away from OCaml is actually a good thing? It brings us more stability, better Windows support and we can cultivate our own pragmatic culture. We can be more pragmatic and only adopt things which is useful to our platform.

Stability: For example, in the latest release, we removed the Marshal module, this module was never supported, any use of its API would cause a runtime crash, so in theory it should not break anything unless you had a crash before. But it does break some important packages, since it used a ppx which used Marshal, I have no idea why Marshal is needed.

Another example is that recently in OCaml community, they are shifting to a new macro lib (this happens every 6 years, camlp4 -> camlp5 -> ppx -> migrate-parsetree -> ppxlib), they reserved deriving attribute name which is in conflict with our own built in attribute, do we need to change our names to be compatible?

The other constant complain is that our compiler is not using their latest bleeding edge version. But for the JS platform, does it really matter which minor version do you use? The difference is very small even between version from 4.02 and 4.12 from type system point of view. In the native world, the multiple thread support is coming, however, it does not exist in JS platform, do we really need to be compatible with such features? Our type system has been developed for many years, and you don’t want to change it for non obvious benefit.

Windows support: windows support is important. I don’t use windows in daily jobs, but still spend lots of time to make windows version work. Without windows support, the project won’t happen since my previous employer is a windows shop. However, most native tools in OCaml does not work on windows, if you happen to use a ppx in native toolchain, your ReScript libs probably won’t work on Windows. The sad thing is that this does happen, for example, Relude does not work on windows due to a use of ppx and it has an impact on all its dependencies.

Legacy issues: OCaml has been there for almost 30 years (counting caml-light), its design show its ages. To avoid breaking the compatibility with OCaml, ReScript does not have a good story in things like unicode support, this is embarrassing. The good news is that we decide to fix this despite of breaking compatibilities. This is just one issue, there are many other corner cases that deserve a clean up.

Note this is not a critique of OCaml, we appreciate that it enables us to build such a great alt-js compiler. The compiler will still be developed in OCaml, which is similar to Flow, Rust, Haxe, Opal etc.

I am thinking that it will be good that we as a community reach a consensus that ReScript is its own language so that we can move forward; the majority of ReScript users don’t need touch the OCaml toolchain. This is good for OCaml too, they have a very high quality compiler js_of_ocaml where they can focus on its improvement.

This is my confession and I would like to hear what you think.

40 Likes
2

I am just speaking as a user that don’t enjoy JS by itself, find Flow acceptable but with flaws (same goes for TypeScript): I just enjoy having a good language that compiles to JS, easy to use, fast with a JS like syntax with easy way to write bindings. And for that, ReScript is better than JS+flow or TypeScript imo.
I agree with everything you said. I would have loved a language that can compiles to JS or native, but I heard enough that it’s a dream that could come true but with a considerable amount of work to be stable enough for production. ReScript is good by itself for what it want to offer and that’s a good thing.
Technical choices you mentioned seems totally legit. Thanks for you work!

17 Likes
3

Disclaimer: I’m not speaking for my employer or my colleagues :sweat_smile: We use both OCaml and ReScript, so some (or even most) of us inevitably take OCaml compatibility close to heart.

With that away, as a ReScript enthusiast I think I agree with your points. ReScript is definitely the best compiler when you’re targeting JS. Granted, I haven’t tried neither JSOO, nor the-one-that-shouldn’t be named, but neither do I want to: I’d prefer not to deal with the complexity of Dune etc. in my pet. Sure, people already familiar with OCaml ecosystem may want to keep using the existing tooling, but I doubt the majority of the frontend devs (or Node/Deno devs) need that complexity.

As for the newer OCaml features, I think the most attractive things too many is monadic let, because it helps to alleviate the leftward drift, and allows a neat syntax for async/await and beyond. Then again, @chenglou is right: there’s not a lot of leftward drift in React apps, even if you account for option, result, etc., so having sugar for it is not that urgent.

I was thinking about it just recently when I read about the Koka language: OCaml is good, and its modules are rater great, but it’s probably not the end of evolution. Also, if ReScript is not bound by what OCaml can do, maybe it could simplify some things that are now more easily and elegantly done in TypeScript, like deriving types of JS object from other objects, iterating over objects’ keys/values, etc.

As for the community, obviously, most of the early adopters came from OCaml (or other FP languages). Some were disappointed with the team’s design decisions (like pipe-first approach) even before the ReasonML/ReScript split, some are in the process of being disappointed right now. I think this is inevitable. Sure enough, ReScript has a lot of existing production users already, and it’s bad karma to move fast and break things, especially in minor versions, but setting expectations is probably the right thing to do.

And BTW, I don’t know how many existing ReScript supporters are the OCaml companies, but maybe it makes sense to start tapping into the power of newcomers (and individual devs in general), and, e.g., setup an OpenCollective account? Also, how about some swag? :grin:

3 Likes
4

The only thing I would mention here is macro lib support. As I understand usage of ppx is generally discouraged, but there are a lot of valid cases to have user-land preprocessing code. If we had our own way to preprocess code not compatible with ocaml ppx, I would be fine with that.

9 Likes
5

I came here by way of ReasonML and then had to take a short break and when I got back to it was shortly after the rebranding from BuckleScript to ReScript. So I never had much invested in OCaml. I love the idea of giving JS developers a better option than TypeScript and something that produces better JS than other compile to JS options. And of course there is the syntax that looks even more closely aligned with JS than Reason is.

I believe the biggest thing that will help build community is information–how does somebody new to ReScript actually build an application? As it stands right now you have to rely on books/tutorials/courses that were created for OCaml, ReasonML, or another close ML cousin. A lot of times figuring out the ReScript syntax requires using the ReasonML playground and pasting in the Reason/OCaml code and then go to the ReScript playground and hope the Reason code translates to ReScript. As people gain more experience it’s probably safe to assume more tutorials and other resources will show up. Maybe @yawaramin can put out a new edition of his book using ReScript syntax (wink wink).

But we know the team is working on producing a quality product and we definitely appreciate you all answering our noob questions in the forums in your spare time because a garbage product with exceptional documentation, books, tutorials, etc. is not a solution either.

I think the fact that somebody realizes this is a concern bodes well for ReScript. Since the ReScript web site is built using ReScript that may make for a good tutorial to walk people through how to use ReScript effectively because we could probably find code katas and other things to practice writing code in ReScript but practice only makes perfect if you’re practicing based on having learned to do a thing correctly in the first place :grin:.

4 Likes
6

allows a neat syntax for async/await and beyond

I agree, it is something we want to invest, but any language-level feature takes time that we can not make promises.

If ReScript is not bound by what OCaml can do, maybe it could simplify some things that are now more easily and elegantly done in TypeScript, like deriving types of JS object from other objects

Yes, something already benefit from this diversion: int polyvar/string polyvar. We did discuss providing a type safe Obj.assign for structural objects internally.

Some were disappointed with the team’s design decisions (like pipe-first approach) even before the ReasonML/ReScript split.

Indeed, but even for OCaml fans, they will miss the good error message provided by pipe-first, see a recent issue reported.

I don’t know how many existing ReScript supporters are the OCaml companies, but maybe it makes sense to start tapping into the power of newcomers (and individual devs in general), and, e.g., setup an OpenCollective account?

Currently, most of us working on this project have a full time job. Maybe we need set up such an account, thanks for bringing it up.

Note I want to make a clarification on how the decision process is made. It is pretty similar to other languages, it is people who hold stakes that form the teams and make a consensus. If you make a consistent contribution to the repo for a long time, you will be invited to the core team. That’s how we have Patrick and Maxime on the team.

1 Like
7

but there are a lot of valid cases to have user-land preprocessing code.

I agree. There are different cases: if you are making a library to be consumed by other OSS users, you are encouraged to check in the generated code to cut the dependencies. If you are doing an in-house development which is not planned for OSS, it is a valid use case to do some ppx since you know what you are doing.

It would be nice to have a macro system which does not rely on the internals of compiler API.

8

A lot of times figuring out the ReScript syntax requires using the ReasonML playground and pasting in the Reason/OCaml code and then go to the ReScript playground and hope the Reason code translates ReScript

This is not ideal. In the new release, you can achieve this within CLI, rescript format -stdin

As people gain more experience it’s probably safe to assume more tutorials and other resources will show up.

I agree, it is a painful process during the transition. What worried me the most is actually the toolchain, we don’t want some random changes in the OCaml toolchain cause a large impact over the rescript users (which includes users using ocaml/reasonml syntax).

Currently the core tools, editor, compiler, build system are all owned by us so it should be quite stable. The only exception is ppx which could pull in the whole ocaml universe.

1 Like
9

This is my perspective, as a fairly seasoned engineer who’s been using ReScript for about three years and is on decently sized team of ReScript developers with a number of projects in production.

I might have some criticisms but I say all of this in love because I appreciate your hard work. I wish I felt like I could contribute more to the community and maybe if I can better understand what is going on, I will be able to.

On community:

I’d caution against confusing Growth and Community. Community doesn’t come from growth alone but from like-minded people who are able to feel that investing their time in your project will be good for
them and for you over the long run… or even better, that they can feel like it’s our project.

I often see people in other projects spend so much effort trying to make things beginner-friendly (in the interest of growth) that they alienate the people who have graduated from beginner and are now
trying to solve harder problems. A lot of core community growth comes from people trying to solve specific problems for their business/project that the language doesn’t solve for them (and
usually, the language shouldn’t solve those problems because it’d just grow to the point of unmaintainability.)

Those people are naturally going to be on the edge of things, using uncommon features, reading compiler code and probably doing things that you aren’t comfortable with. Those people are also key to growing a community because they are the most invested. Without those people, you just have a churn of beginners. But, reading comments over the past few years, I can see those people feel alienated. Mostly, I believe, because of mismatched expectations.

Maybe at beginner you just care about understanding things and getting things compiled and running… JS FFI, testing… the bare minimum. But once you’ve done that for a while and you hit the next level, you start looking at solutions to the other real problems. Maybe they’re problems that required by your business to put code in production, or maybe they’re just annoyances for your team. Things like reducing boilerplate, strengthening your typing, better designing your domain models, code coverage, automating manual tasks. At the moment, all of those things usually move people closer to OCaml than ReScript.

For example, my team writes server projects with a ton of control-flow logic. We have some frontend code too but for the most part we’re not writing projects where we can just lean on React to do a bunch of heavy-lifting for us. Infix operators and the PPX for let bindings (not await. I avoid promises like the plague) make our lives so much easier. We like ReScript AND we like those things. We’re professionals
writing production services, we are making these decisions for good reasons and we don’t need someone in the forum making smartass jokes about how x #$ v @#$ z is hard to read. That’s not helpful and it is a key issue that makes me not want to invest in this community.

On OCaml:

I know you say you mean no disrespect. And I understand your frustration… but your attitude in the things you write about OCaml doesn’t really help your points. I think it would be more helpful if you would just say “We won’t upgrade OCaml. End of story.” and move on.

Personally, I consider myself a pretty experienced ReScript user (and a moderate OCaml user) and I don’t really care about any 1:1 relationships with OCaml. If you removed every single OCaml module
tomorrow and I could still compile my project, I would be happy. When removing the Marshal module broke our build, I wasn’t worried about the Marshal module going away… I didn’t even know it existed in
ReScript. I was just afraid that for what seems like the tenth time in the past year, I would have to spend hours/days of my life changing code that worked fine yesterday for reasons that hadn’t (at the time) been explained.

Another example is that recently in OCaml community, they are shifting to a new macro lib (this happens every 6 years, camlp4 -> camlp5 -> ppx -> migrate-parsetree -> ppxlib)

Six years is a helluva long time. They’re solving problems. They’re making quality of life improvements. The reason there is a new macro lib is that it will be much easier to maintain. This is exactly the
problem you see people bring up with ReScript: “Things are changing again? My stuff breaks. I don’t understand the benefits. Why is this happening?..” Well… to make a better, smaller, more maintainable
and enjoyable project.

The other constant complain is that our compiler is not using their latest bleeding edge version. But for the JS platform, does it really matter which minor version do you use? The difference is very small even between version from 4.02 and 4.12 from type system point of view.

From 4.02 to 4.12 is seven years of bugfixes, small features and (most important to me) quality of life improvements. It’s unhelpful for your argument to pretend that this is nothing. Anyone can go read the release notes so I won’t bring all of that up here. There are things in there I would love to have that would improve my quality of life… but not having them isn’t going to make me abandon ReScript, it just makes me a little less happy.

I personally don’t expect you stay on the bleeding edge and I think anyone that does expect that doesn’t understand your goals for the project. But it’s better to say that it’s a lot of work you don’t want to do right now than to say that it is not valuable.

In the native world, the multiple thread support is coming, however, it does not exist in JS platform, do we really need to be compatible with such features? Our type system has been developed for many years, and you don’t want to change it for non obvious benefit.

I agree anyone asking for multicore support in ReScript simply doesn’t understand things. It just doesn’t make sense. But the Effect system they’re building (which is enabled by multi-thread) is a game-changer. It isn’t in OCaml 5, but hopefully it will be in there soon because I think it will redefine how people see the language. I’ve written services in languages with Effect systems… I’ve written an Effect
system. Once you use one you never want to write code another way. I don’t actually expect ReScript to take this on. It’s very difficult. But there is much more work going into that than just “multiple thread support”.

I am thinking that it will be good that we as a community reach a consensus that ReScript is its own language so that we can move forward; the majority of ReScript users don’t need touch the OCaml toolchain. This is good for OCaml too, they have a very high quality compiler js_of_ocaml where they can focus on its improvement.

I think that’s a great idea and honestly, I think you already have consensus. Anybody still around is invested enough in ReScript to see that through. I think it’s important to remember though, that when
somebody asks for a feature that OCaml has, or Haskell has, or Ruby has… or when someone has a problem with a dependency compiling… it’s not always just because they think you need to stay on the
bleeding edge of OCaml things. They’re just trying to solve their problems, they need help, and they could find it in other places.

It’s also very important for you to be happy. And I think it’s important to be very vocal and overly communicative of what makes you happy working on ReScript and what you want to do long-term. At this point I’ve spent as decent amount of time in ReScript and I still just don’t understand what the plan is for anything. Because of that, right now, I don’t contribute to the ReScript ecosystem. But I’d like to.

27 Likes
10

As you are looking to discuss this in this topic I’ll provide some opinions, do with it what you want. I came to rescript from TypeScript because I found it more productive and safe, run a startup that is using rescript in a pretty sizable codebase. I come mostly from using it in a production setting. I am not coming from the native side, I build a web platform iOS app and Android app, but all of them are using React-Native (using rescript), I rarely dabble on the native side (sometimes for some small stuff I need to touch Objective-c or Swift). I did work on the graphql-ppx codebase and thus touched OCaml/ReasonML native, but this was mostly to make myself more productive with GraphQL in our codebase (it was either improving graphql-ppx or go back to TypeScript).

I respect your direction, and it’s certainly something that might be more successful than the alternative. I feel a little sad about it because over the last few years there has been a lot of progress in the OCaml community, and even though it’s a different community I would be happy if both communities could uplift each other. I saw this with Elixir and Erlang. Different communities, but they decided to grow more towards each other, and become stronger for it. Even though the alternative syntax (Elixir) is now bigger than Erlang.

I also think an opportunity is missed with not keeping the door a little open to compile to native. It’s hard to compete with typescript given the former has so much more adoption for incremental improvements (faster compiler, slightly nicer type system), while compile to native would be totally infeasible for TypeScript so it’s a unique competitive advantage that is not easily matched. But that is a more controversial take, and I think you made a decision on that for the sake of keeping the project focused.

I don’t know why windows support is a reason for this direction. I think most ppx’s support windows, if not, that is just because probably the maintainer didn’t compile windows binaries. Windows support is not great and can be improved in OCaml, but staying away from that community will not automatically improve windows support.

This was actually not the case, we just misconfigured ppxlib. Btw the last three are evolutions of tooling around ppx’s, it doesn’t really change the way how you write ppx’s, and it doesn’t affect consumption of ppx’s in ReScript (they just work).

On keeping up with the OCaml compiler. I think generally it’s good to be up to date, because you get many small improvements, bug fixes and some language features that doesn’t affect beginners but can make companies that use it on a larger and more advanced scale more productive. It can also have some second order effects, like making it easier to support the new apple ARM architecture and thus delivering a faster experience to a growing number of users.

So to conclude, due to this change in direction of ReScript going from a compiler backend to a stand-alone language, you are splitting the community up into a camp that philosophically would like to be more compatible/friendly with the OCaml community and keep the door open for a programming language with two targets (native and web). This means you are forcing the hand for a fork of ReScript itself as well. I think that is perfectly fine. The only downside of this is that the project will split up into these two directions and the community for each will be smaller. But the focus it delivers might be worth it. I just would ask you to be collegial and respectful to the people who choose to pursue the original vision and adopt the fork.

For my company I will see which project will make the most sense for us. For now it’s ReScript. But if some changes happen that will make us less productive we might move to the fork, it also depends on user adoption.

10 Likes
11

By the way I don’t understand why you say JSOO is an alternative. It would never be an alternative for us and I don’t think it’s an alternative for anyone who is now using rescript (they would already be using JSOO). TypeScript would be a far more realistic alternative for us. So the only real alternative is a fork of rescript.

5 Likes
12

Thanks for writing such a long feedback.

My vision for the project is to create a language with reasonable abstraction but focus on the quality of the implementation itself. You will always end up writing some boilerplate code even in languages like Haskell. If I do want to use a language for learning purposes, I would choose Haskell. Golang is to other extreme, it has very solid tooling but the abstraction is quite limited. The philosophy of this language is that we want to make a language like Go but with reasonable abstraction (not fancy abstraction), for example, we should have support for generics, ADT, pattern match, basic support for structural typing etc.

My observation is that almost all academic languages are very good at abstractions but fail to do some mundane things poorly. I am okay with the current abstraction we provided, this does not mean we will stop here, it means the priority does not rank high.

From 4.02 to 4.12 is seven years of bugfixes, small features and (most important to me) quality of life improvements.

Not really, when we upgraded from 4.02 to 4.06, we noticed around 3%~5% performance regression, and the size bloated significantly, it does have some good stuff for native like flambda though. My gut feeling is that the classic 4.02.3 has the least bugs.

I think that’s a great idea and honestly, I think you already have consensus.

I wish so, and it is good to set expectations clearly.

4 Likes
13

Hi, I think you already mentioned everywhere that you want a fork. This is OSS, you are free to do it as long as the authorship is preserved.

1 Like
14

Thanks for reading through it all!

My observation is that almost all academic languages are very good at abstractions but fail to do some mundane things poorly. I am okay with the current abstraction we provided, this does not mean we will stop here, it means the priority does not rank high.

I think this is a fairly common observation and is pretty true. Most of the fun languages are more about trying new ideas than building practical programs. I love Idris but I can’t sit down and write a boring business service in it today. Some people say that about Haskell but I’ve taught it to enough junior people to know it can be boring and stable as well as insane.

Not really, when we upgraded from 4.02 to 4.06, we noticed around 3%~5% performance regression, and the size bloated significantly, it does have some good stuff for native like flambda though. My gut feeling is that the classic 4.02.3 has the least bugs.

Ah, I see. When I’m thinking about the updates, I’m not really thinking about size/performance/bugs of the implementation… I’m more thinking about fixes for exhaustiveness checks and better inference/errors around GADTs, refutations, empty variants… of course the std lib stuff has been brought up, the things we’d see in user-land. I understand you have to weigh those other implementation issues when you are thinking about it, which is not something I think about.

I didn’t really want to go listing too many OCaml details in a thread about community building, so I’ll stop there.

If I do want to use a language for learning purposes, I would choose Haskell. Golang is to other extreme, it has very solid tooling but the abstraction is quite limited. The philosophy of this language is that we want to make a language like Go but with reasonable abstraction (not fancy abstraction), for example, we should have support for generics, ADT, pattern match, basic support for structural typing etc.

This sounds practical. I guess the question is where does a community actually fit in here? I’m sure there are people that would like to become more invested but it seems like it’s not an easy thing to do right now.

15

Personally, I think you and the core team are doing a great job stating what you want for Rescript, and slowly making everything consistent and great for that direction.

Stick with your vision, keep communicating clearly and doing the work, and the rest will follow. There is a big gap between the super restrictive Elm safety and the uncertain false security of Typescript, and Rescript fills a very valid use case.

A couple of suggestions that would be useful for the community in my opinion:

  • A roadmap of things that are being worked on or considered (either on the website or pinned in the forum somewhere)
    • You have all been doing a great job communicating, posting announcements in the forum, and engaging with everyone. The only thing missing is a peek into the future somewhere it is easy to find and link to.
      For example, are Belt and Js going to be cleaned up or merged at some point? Is there going to be some sort of async/await syntax to ease asynchronous programming? I don’t know, and I’m not in the github issues but it would be good to know what the core team has in mind for the near future.
  • Clearer guidelines for contribution on the different aspects of the language
    • Right now there is some information here rescript-lang.org/community/overview but it is mostly a bunch of links.
      It would be beneficial to list how to contribute to the different aspects of the language. What do I do if I want to help improve the docs or website? What do I do if I have an error that looks like a compiler bug?
      Writing these down somewhere also helps other community members link to guidelines when people ask or have a need. Authoritative sources of information are very important
6 Likes
16

Let me explain a little bit that more abstractions beyond what we provide may only provide the marginal benefits.

Languages are used for communication, people only have 8 hours day. So if someone is an expert in some domain, probably he may lack some knowledge in other domain. As a community, we need people who have different expertises, not just PL experts. For example, most data scientists are not interested in learning some fancy abstractions, but they have some domain knowledge that you don’t know. We need a way to talk to each other.

If we keep optimising in the direction of providing more fancy abstractions, it makes the communication more difficult with people who have no interest in PL.

I know it is painful that we can not do fancy stuff in a language we like, it is something we give, and hopefully we will get more in return.

5 Likes
17

I understand about different specialties and I think its a good point. I usually don’t communicate with people in other specialties by having them read my source code. I communicate with diagrams, presentations, discussions, and online tools like Figma, Google Docs, Storybook, etc.

2 Likes
18

For example, are Belt and Js going to be cleaned up or merged at some point?

Indeed, that’s something I am planning to raise up in the team meeting next week. Our team is highly distributed, they all live in different timezones, so the latency may be much higher than you expected.

1 Like
19

Yup, agreed.

I don’t want you to get the impression I was pushing for any kind of crazy further abstractions… I hope I didn’t say that. I don’t think I did. I think the level of abstraction we’re at now does the job very well. I only brought up the changes around GADTs as an example of the OCaml work over the time period you mentioned… they would make my domain models nicer but we get by just fine without them now.

I think I mentioned… I’m by no means a PL expert. I have a little bit of experience working on them but what I use ReScript for is building regular old production services on a team of people with various skills… just like anybody else. And that’s all I want from ReScript, so I can very much appreciate keeping things practical.

5 Likes
20

I think the main source of frustration in these conversations about ReScript becoming “its own language” is that there’s a big gap between what comes to my mind when one hears that vs what reality shows, from a technical perspective. ReScript has done a ton of great work over last years, but it started as a fork of OCaml (actually two forks, also forked ninja), so it’s not a “leaky abstraction”, it is like one is still “swimming” in OCaml when using ReScript.

If the future goal is that ReScript becomes its own language, it would help to avoid frustrations on all sides (including core team) if the team defined a roadmap to remove features that were inherited by the project being a fork of OCaml, but are not needed for the long term goal of the project: becoming the best language for JavaScript developers.

Some quick examples: stop supporting pipe operator |> , remove ppx-flags from bsconfig, stop supporting ml syntax, don’t use external for bindings, etc. I am sure there are plenty more.

Otherwise there is still too much of OCaml being exposed to users through so many paths. Some of these paths like ppxs do not expose just some tiny OCaml functionality, it is the whole language + toolchain that is being exposed. I see all these exposures as a liability / weakness on the path to the ReScript future explained in this thread, as I understand it.

If ReScript history taught all of us anything is that every feature “inherited” from OCaml, but not being part of the main ReScript goal of supporting JavaScript users, will potentially become a source of problems on some future update, with the consequent frustration for both users (“why did my code break?”) and maintainers (“why do I have to do extra work to fix something that will not help at all to achieve the main project goal?”).

I understand planning and removing this functionality is a ton of work of course, especially ppxs, but not everything has to be fixed tomorrow. Just having a place where one can see a list of these OCaml-inherited features that are “intented to be unsupported at some point in the future” would be a huge improvement over current state of things, where these features are discouraged by core team members in random forum posts, or hidden from docs, and then seem to be removed in an improvised manner, with the consequent frustrated conversations due to misaligned expectations.

18 Likes