Some thoughts on community building

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
30

The other day I was searching for something and one of the search results took me to an OCaml forum and an older discussion about the purpose of BuckleScript. I have to say I was really disappointed in the attitudes of many of the experienced OCaml developers’ towards BuckleScript and its developers. After reading that discussion I think the ReScript devs made the only choice they could make by making ReScript its own language. I really could not understand people having a problem with ReScript targeting JavaScript developers particularly when their main beef was “We already have js_of_ocaml (JSOO), why do we need BuckleScript?”

I can understand people invested in ReasonML being concerned because of the ReasonML/BuckleScript connection. But I find it interesting that people complain about ReScript targeting JS developers as if it’s a foreign and pointless concept. Yet we have Elm, PureScript, ClojureScript, Fable, that all exist as functional programming options for JS developers. I know ReScript isn’t selling itself as a functional programming language but one is certainly not going to be using it to do OOP-style coding.

Now it’s possible that people using ReScript on the backend may need more powerful features than what most people need to be productive on the frontend. But I think the devs are taking a good approach by staying close to why they wanted to create ReScript and when they are doing that well then start adding more “advanced” concepts/features if there are enough people that want the feature to justify expending cycles on it.

@hongbo explained very well in that particular forum discussion the challenges in trying to get teams/managers to adopt OCaml and how BuckleScript made it easier for decisionmakers to feel comfortable moving to a language that would help developers produce more reliable applications.

Frankly, I wanted to like TypeScript but it reminded me too much of Java and all the Java cruft adopted by dynamic languages to woo Java developers. The syntactic sugar won me over to ReasonML over OCaml and I find ReScript an improvement over ReasonML/BuckleScript. Maybe I’d think differently if I had learned OCaml first but as it is I like ReScript. I anticipate the JS interop will only get better and that there will be more documentation and tutorials as people gain more experience.

If you’re not doing React development maybe one of the other compile-to-JS options will do, but for me there is no way I’m going to be able to integrate one of the other options that produce near-unreadable JavaScript into any of my projects at work and the only alternative that would be acceptable is TypeScript with allowable “any” types :scream_cat:

Well, this is longer than I expected but I just want to say I’m thrilled with the direction you guys are headed because there is nothing else that is trying to do what you are doing. I think as long as the team communicates what it is doing and why, everybody may not be happy but I believe most will appreciate at least having a heads up about pending/potential changes.

9 Likes
31

Indeed, I felt heart broken in that post, it was a tough week but I moved on.

The best thing you can do is just focus on thing you care.

10 Likes