that’s some great news, some clarity in our ecosystem (and especially for its most common use-case, the JS target) was more than needed
This is really nice. Though I wish we could keep the same forum.
One thing that is conspicuously absent in the ReScript messaging (see for eg. https://rescript-lang.org/docs/manual/latest/introduction) is any mention of OCaml. While it simplifies how the language is communicated to new users, it removes a lot of historical and social proof that OCaml brings.
For example I’m part of an initiative that is trying to bring Reason/OCaml education into India’s engineering curriculum that could be adopted nation-wide. Right now the pitch speaks well to the academic community thanks to OCaml’s pedigree. I wouldn’t have been able to pitch ReScript as a new independent language without that. Similarly we also evangelize the language in engineering shops we interact with, and sometimes mentioning OCaml lights up someone because they’ve learnt SML thru the ProgLang course, or if they’ve already worked with a Hindley-Milner based language like Elm or Haskell.
I’m afraid my personal efforts to bring the language to more people will become more difficult if ReScript is construed as a new language that has to prove itself in all fronts.
That’s amazing. Wouldn’t it be a solution to use ReasonML instead of ReScript for this more advanced crowd?
The students would be undergraduates (if the proposal gets accepted), and being a large and diverse group, their programming competence would be all over the spectrum. We have to treat them as beginners and so the course is about building robust front-end software with Reason. They’ll learn all about types, modularity, and FP while writing code on the browser. The course is also industry-oriented (that’s our value prop) - learning it should give them practical skills that’ll help them find and hopefully use in their jobs. All these makes BuckleScript the ideal choice. Also, I haven’t been able to put native Reason into production (mostly my lack of attention there) so I don’t have a compelling pitch in that direction.
If you’re interested, here’s an experience report for a course in a similar vein that we ran last semester: An industry-led, fully remote programming course for Indian B.E/B.Tech degree.
Apologies for derailing this post, happy to talk more about this in another thread.
Hi @chenglou, wondering what the plan is for editor support. Will there be a new project? Or will an existing editor plugin be adapted?
There is a lot of reference to “Reason can now focus on x” in the messaging – does this mean that long term, Reason will no longer be a compile-to-JS language? As I understood it, BS was the JS compiler for Reason, and now it is entirely separate? Is that the ultimate goal?
When I was watching the conversation about
.res there was that thing about the answers that were given that seemed incomplete. That bell that rings that says, you know what, that sounds like it doesn’t make sense. In that last few days, both the
gentype docs/examples and the
bucklescript docs have switched to
.res, apparently without giving and option for
.re. Not for nothing, I asked this exact question during the conversation. Right now a search on the bucklescript site redirects to
.res documentation on https://rescript-lang.org/docs/. Should we understand the
.re based docs are
frozen? Will they be left up? For all the talk about overhead in the elegantly written post, do I need to add the overhead of mentally converting the
.res docs to
Honesty don’t understand what is going on here. Basically, what is the deal with Reason?
I, for one, am greatful for the Reason days of old that got me into OCaml.
Note: I see that there is a
.re/.rei syntax converter tucked away on the new site here: https://rescript-lang.org/try.
Is this script available to be uses locally?
The .re docs are indeed left up at reasonml.github.io (which actually is still the official documentation site of the Reason language right now). That site won’t be removed because otherwise existing users wouldn’t have the documentation syntax for their current .re projects. That site will also hopefully keep improving on its own. As for this newly released doc site, we’ll keep an eye on the situation to see if we’ll reintroduce the .re syntax temporarily. It’s just that during the rebranding, it made less sense to go the route of having a single doc site that also includes all of current reason doc site’s stuff (and remove the old reason doc site), because folks who are already familiar with reason and the docs already would have to reorient themselves for no extra benefit, and new folks would find the double syntax and flip-flopping explanations confusing (removing that is half of the point of the rebranding).
As for Reason support in ReScript (aka BuckleScript), please refer to our previous post.
Sidenote: the Reason language manual on reasonml.org is actually the same as on reasonml.github.io, since most doc improvements on reasonml.org were targeting BuckleScript documentation. These docs were taken over to rescript-lang.org and have also partly been merged with the ReScript language reference (there used to be a lot of duplicated content between syntax / bucklescript features).
So reasonml.org will be for the native part at some point?
Also a Belt without a Buckle makes no sense anymore, will the stdlib be rebranded too?
(Or rather aliased).
Yes, depending on how the Reason team wants to handle their docs in the near future (I guess it’s up to Jordan to decide), it should ideally be refactored to Reason Native content to cater to their target group. So far I couldn’t find any technical writers for this, so in case anyone is interested in pushing this further, I am happy to give advice and access to the website infrastructure / domain.
For the time being, the BuckleScript content on reasonml.org will stay for existing users.
I wonder what happens to the fast pipes in ReasonML [native] now. I know they have some other pros, but their raison d’etre prorbably was that it was more natural for people coming from JS. And now it seems like Reason is going to be predominately used by people coming from OCaml
ReScript is a language which shares the same type system with OCaml, would this make sense to you
Yeah, I think the Reason modules and opaque types are great for information hiding, so the ReScript learners should get to know them. Whether or not they should know of their OCaml pedigree, depends. E.g., I think students could benefit from some papers on SML/Caml, so for them, it’s useful info. For working programmers that have a lot of other things on their mind (maybe the biggest part of ReScript intended audience), maybe that’s too much information. --provided the information on modules and opaque types in ReScript, maybe with some best practices, is there.
But that means the information on modules etc. should be available in ReScript docs and learning materials. And I think there should be much more of those than there is now. I mean, much as I loved, say, @yawaramin’s book, if you want to be really good in Reason, it doesn’t cover everything that, say, Real World OCaml covers, so to get better at Reason in 2020, you probably still have to know OCaml.
I just got that for the first time…