Some thoughts on community building

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
32

I think all new languages – even on existing platforms – need that to succeed. The “better TypeScript” that people will adopt is TypeScript next year. I don’t think that’s a winning stragegy for ReScript – it’s not a library.

So I worry that ReScript might be in the process of either losing its own USPs, or pushing its rebranding so far that people think it has.

But what do I know, that might not be the path you (as a team) go down, or you might go that way and suceed. And either way I do expect to enjoy the results of the improvements you’re making.

OK, no more of that from me :slight_smile:

5 Likes
33

I just made an account to discuss this exact topic :laughing:

I’ve been using ReScript for over a year now and love it. However, the lack of visible community has been concerning. Here are two actionable suggestions:

  1. A Roadmap
    Make this big-and-visible on the homepage. Get people excited and set expectations. Don’t make changes feel like a burden or surprise.

  2. Newletters
    A good newsletter keeps less active members informed on changelogs, conferences, community articles/libraries/products, job postings, etc. This is my prefered way to get developer news. Ruby, Elixir, and CSSTricks have great newsletters to mimic. Even emailing only the blog posts would help.

11 Likes
34

I don’t think this point is very important, but I generally have two categories of languages that I recommend to people. There is a category of languages that I would recommend to others because it seems like a choice that isn’t too difficult to learn and navigate, with some elements of what I am excited about. I put scala, elm, ReScript, f#, and clojure in this category. Then there are the languages which I would be excited to use. I put ocaml, purescript, rust, and haskell (and reflex-dom) in this category. I put more effort into advocating for the second category of languages, which is free marketing and labor for that language. ReScript used to fall within the second category for me. Overall, I don’t think free marketing is that valuable.

2 Likes
35

One thing that might be able to help out, is getting like a rescript course out there on Udemy.

There are a few instructors with great scores there, and a fanbase to just buy courses simply because it is of “X” instructor. Perhaps it is worth some consideration sponsoring an instructor to write a course on Rescript.

There are quite some good instructors, but one of my favourite is Stephen Grider, and I recall him saying he might do a reason course some day (but that was a few years ago). I think perhaps now is a good time to get started.

2 Likes
36

Beginner friendly Forum

I think that the onboarding on this forum should include welcoming messages for beginners.

I’ve seen several people starting their posts with “I wish there was a category for beginner questions”. Beginners should feel at ease of posting their “stupid” questions. I feel that they perceive this forum as for Experts-Only. Myself I’m not an expert but I’ve been using Rescript for more than a year. Coming from the Discord chat, I knew that this forum was beginners-friendly. But others who land here as their first contact with the Rescript community might feel intimidated.

3 Likes
37

We actually did that recently!

^ This particular post should show in the pinned message when they join for the first time. I also think they will get a notification pointing to that resource if I am not mistaken?

3 Likes
38

Maybe there could be a dedicated “small questions” topic? (Not even necessarily for “beginner” questions.) I think there’s some hesitancy people experience when they want to ask a seemingly small or “noob” question and they’re expected to create a new topic for it. Replying to an existing topic (or asking in a Discord chat) feels like less of an investment.

4 Likes
39

I’ve seen some Reddit channels creating a topic for beginner questions weekly so that it doesn’t become one overlong thread.

4 Likes