Some thoughts on community building

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
21

I strongly agree with you in general, but what’s wrong with external? To my understanding, the fact that it’s the same keyword that OCaml uses doesn’t have to mean it has the same semantics. Of course, maybe I’m missing something.

Again, this is just a nitpick, the gist of your argument is totally valid, IMHO.

22

Using external was a free feature for bindings, thanks to OCaml inheritance. But there could be much better ways to allow JS devs to define bindings, see https://github.com/rescript-lang/syntax/pull/217.

2 Likes
23

I’ve stepped up into ReasonML and then ReScript from the JS-side. I’ve never used OCaml before that, neither I’ve used it after that. The fact that ReScript is using OCaml somehow is an internal implementation detail to me. I understand, that a huge portion of work belongs to OCaml without which ReScript would probably never exist, this deserves respect. I’m respecting OCaml’ers, but that’s all my attitude to OCaml.

ReScript on its own is already a great modern language targeting JS. You can make front-end and back-end with it. I’m running some NodeJS services written in ReScript and it’s OK, I’m happy. I am very sure that there’s a huuuge number of devs who would fall in love with ReScipt never knowing that it is powered by OCaml somehow.

The disputes mentioned happen because the current community is in its big portion came from OCaml-world. It’s OK and valuable that they share the thoughts, concerns, and cautions. This can help to stop some very coarse moves.

But what the community lacks IMO is fresh blood. Much of new, evenly biased, fresh blood. Among other things, the community begins with trust. And can I trust a new language/platform and invest my time and energy in building something great with it? Looking at the current start page https://rescript-lang.org/ I don’t know. Will it survive or collapse like many-many new hype languages/technologies?

The thing that convinced to try ReasonML in production is the statement that Facebook Messenger is done with it. Not a bullet-proof argument but it creates some level of initial trust. Some may argue that it’s a kitch-marketing to show “Used by Viola, Coca-Cola, Motorola” on a start page but it works.

So, c’mon, don’t wait for something, make the bold “Used by” section or page, make a “What devs say” section. Seed the trust, acquire new folks. Dilute the number of OCaml-compatibility posts with a big wave of new topics from the new members.

I think it’s fair to list ReasonML/BuckleScript projects and companies there too. Because it’s the history of things, it’s your merit. Collect as many projects/companies/reviews as possible. Later, you can always leave only the big boys on the top and move others under a “See more…” button.

13 Likes
24

One thing is that once WASM supports GC, OCaml will (hopefully) get support for targeting WASM. It might be desirable to keep that door open.

Although other than the compiler core, I don’t have any issues moving away from OCaml toolchains and libraries. I’d love to see the OCaml stdlib replaced with Belt, and (controversially) making uncurried functions the default.

3 Likes
25

Hi, thanks to all who get involved in this discussion, it is great to have such conversations.
I was a bit lost since I spent so much time in making existing OCaml users happy, actually I prioritised some of their feature requests in general and convinced our team to support infix operators. I am happy where we are now, it is time to turn on a new page: Rescript will get evolved in its own direction, let’s move forward!

Some clarifications about the backwards compatibility, we are responsible for what we offer in general:

We don’t remove things just because we don’t use it.
We only remove (or not support) those features under such conditions:

  • It does not translate well to existing JS semantics.

  • The maintenance overhead is nontrivial compared with the benefit (we are a small team, we want the development to be focused)

  • For some patterns that we discouraged, and plan to remove, we will make a heads up notice to make time for you to be prepared, it will be similar to this, or we will emit a deprecation warnings first and remove it in future releases, so please don’t ignore deprecation warnings.

  • We remove things which are never supported, take Marshal for example, none of the functions in this module were supported, so unless you use fancy things like ppx(we will expand on it later), this should not be observed.

Suggestions on ppx

  • If you are doing in house development, you know what you are doing, so feel free to do whatever you want.
  • Think twice before you need ppx for a publicly released library, trust me it will shorten the life cycle of your projects once you have less time invested in it.
  • If you do the ppx against our specific ABI versions(not the ocaml native toolchain) , we will provide guidance and help as much as we can but it will be the best effort.
  • If you are doing ppx using macro libs (e.g, ppxlib) which are not specific to our ABI versions, you are responsible for yourself, and I would consider this project of high risks. Imagine if some random native ocaml toolchain changes, for example, the Marshal format gets changed(this happens rarely but could happen), you will have a segfault for such ppx, then your project will no longer work, we will not do anything for such things.
  • We would like the majority of rescript users to walk away from the native toolchain in general, it is a good thing for the community since things will be much easier to share and guaranteed to work in a long future and it will work on Windows out of box and does not depend on a post-install. The critical part of our infrastructure only depends on a vanilla c++ compiler toolchain, no more moving dependencies so you should have confidence in our project.

Some clarifications on the history of the project:

  • This idea of this project was novel and born of this idea, it is not a fork, the commit history is all available on github.
  • It has some dependencies which are vendored and patched based on our needs, but I do not consider it a fork, for example, the reason I patched ninja is to improve its performance, it is not in our interest to re-sell our patched ninja to make the original work look bad and we give credits in the beginning. These are implementation details.
  • I have deep respect for the OCaml language, Xavier Leory is one of my most admired computer scientists.
7 Likes
26

Just to clarify: you’re supporting infix operators now?

27

infix operators are still in the impl phase. It needs to be designed in a way that doesn’t introduce a lot of parsing overhead and syntactical ambiguities (for meaningful error messages). Don’t get too excited about this though, it will most likely have limitations.

1 Like
28

Here are my thoughts as a total newcomer to ReScript. I think @nkrkv has an excellent point about building trust. The story about Messenger’s bug rate almost dropping to zero because of ReasonML was also what caught my attention. Stories like that are great because they attract attention and, more importantly, builds trust.

So how can we build trust around ReScript? I’m not sure. But I have a few thoughts about what would build trust for me.

I would like to know what motivates the team around ReScript? What is it that makes you create these great tools for us? How can we help keep you motivated?

On a more personal note, I must say I miss having a place like Discord. It somehow feels alive when you can log on and participate in casual conversations with like-minded people. For inspiration, have a look at what @zth is building around rescript-relay. He is creating a healthy community leading by example by being kind and helpful. It feels inclusive, and I’d love to have a similar place for general ReScript interactions.

But overall, I can only be pleased. We’re so blessed to have something like ReScript; thanks for creating it! It makes my day a little better. Better for the obvious reasons; fast compilation, strong type system, etc. However, the main thing for me is that I’m just that little bit happier writing ReScript code than the alternatives.

I’m betting on ReScript. I hope more will join me!

8 Likes
29

I thought I’d chime in since I think I’m quite close to the target user that the ReScript team is hoping to target. My usage of ReasonML is currently on the server side using Nodejs (I chose it also hoping to use it with React as well).

I’m a typescript developer who then read a functional programming book in F# (Domain Modeling Made Functional https://fsharpforfunandprofit.com/books/), and then learned by implementing some production libraries using Ramda (JS functional helpers without the category theory), followed by more advanced experiments involving more category theory using fp-ts (excellent library and author who writes great articles). At some point the verbosity in trying to do stuff with fp-ts lead me to consider adopting ReasonML. It had the excellent Relude library which filled in for fp-ts but now I didn’t have so much boilerplate just to define algebraic data types, not to mention other benefits of the compiler. Plus I could seamless integrate my ReasonML code with my existing Typescript codebase. It was a no brainer.

However I don’t think I would have considered ReasonML at the time had I not already dabbled with functional programming, type-driven design, and the basics of category theory. I don’t think you can convince an English speaker to adopt Chinese just because it’s written in Pinyin (Chinese written with the latin alphabet). Sure they can read it and it simplifies the learning process greatly, but the grammar, vocabulary, and idioms will still be completely different and constitute the greatest bulk of the learning process, as well as the greatest bulk of the benefits. I believe ReScript is fundamentally quite different from Typescript, and a superficial syntax similarity is not really enough to switch people over without also teaching them the benefits of the Result monad, algebraic data types, etc. Its differences from Typescript and its Ocaml roots are what I believe to be the strong selling points of ReScript. While I respect that it’s not necessary for a lot of use cases to go full Monad, dipping your toes in this universe will inevitably lead to more of it as you progress and possibly refactor your code as you encounter more applicable use cases and a greater understanding. I think both Scott Wlaschin (https://fsharpforfunandprofit.com) and Mark Seermann (https://blog.ploeh.dk) are mindful of practicality and do a great job teaching category theory concepts (they are .NET developers), and they do a great job teaching concepts like Monads and their applicability without even mentioning the word Monad. Their primary language is F#, which at this point is practically the same as ReScript, so everything they teach applies to ReScript still. There’s always a place for higher level abstractions, so I hope that ReScript does not tend toward lowering that ceiling at least from what it has inherited from Ocaml. I’ve never written ocaml so I don’t necessarily care about direct Ocaml compatibility, or losing a feature here and there.

Tldr; I don’t think removal of features or superficial syntax similarity with Javascript ultimately do enough to convince the average Typescript developer, who either has no interest or no knowledge in functional programming or category theory, to switch over. It certainly will hurt the more advanced, and therefore more invested, users more than it helps any new people adopt ReScript. I want a language that is MUCH better than TS, not just slightly better, and a lot of the better comes from conduciveness to enabling more functional paradigms. I’m making all my developers learn ReScript and I am using it on production code in a real company.

I hope this opinion helps and I definitely want to thank the ReScript team and contributors for their hard work. Even in its current state (where I may disagree with some of the direction it’s heading), it’s an amazing piece of software that has helped completely changed the way I program (for the better). I humbly hope you guys will allow me to continue in my journey to improve myself as a programmer.

14 Likes