Remain consequential in a typescript ecosystem?

,
1

Rescript launched around 2020 as since then has been called ‘Javascript from the future’, by compiling to JavaScript while offering a fixed set of syntactic, semantic and logical improvements to the language, notable features like Hindley-Milner type system, type metadata conservation, pattern matching, pipe operator, if/else as expressions, automatic currying, decorators, and embedded JSX make the language interesting at first sight, however months after finding it, i can offer a different perspective about which may be another “Javascript from the future” and may has always been.

I recognize Rescript as a Javascript from the future, in the sense it has features missing from the Javascript of the present, however Javascript from the future may become more feature parity with Rescript, here’s a listing of some relevant ECMAScript proposals:

Rescript already has those features, but also has some limitations, the dominant language for web development i believe it’s typescript, even if some people still use plain javascript, the general direction is moving towards typed web development (hope this is obvious), and Typescript is now like a Defacto unofficial standard, there is even an ECMAScript proposal for bringing types to JavaScript

Currently you can consume Rescript from Typescript using a tool called GenType, however you can only consume Rescript from Typescript but not Typescript from Rescript, which forces you to develop and maintain custom bindings, which make Rescript not as viable option for long term projects using 3rd party libraries from the typescript ecosystem

If you prefer the standard Typescript ecosystem, then you are already have a “Javascript from the future”, which supported many ECMAScript features before they reached mainstream, like classes, optional chaining and null coalescing operator, or features on the road like decorators and type annotations.
Basically, typescript more than a “Javascript OTF” is like an evolving futurist ECMAScript guinea pig.

Rescript will follow its own path of perfectionism, where Typescript will not fit, those who are brave and discontented with the status quo can always join efforts in any side, thanks to the Rescript team for an awesome language, the future of Rescript, I believe, depends heavily on the community, can’t wait for it.

~ A fellow

1 Like
2

A few thoughts on your perspective.

ReScript launched in summer 2020.

…lots of stuff about TypeScript…

Sure, TypeScript is the dominant typed AltJS today.

there is even an ECMAScript proposal for bringing types to JavaScript

Sure, but that’s specifically for type annotations, not typechecking. It looks like it wants to standardize TypeScript’s specific typing syntax. Which may be fine–but based on past history, some people may not like a standard which effectively has only one viable implementation.

If you prefer the standard Typescript ecosystem, then you are already have a “Javascript from the future”

Except for the features like pattern matching which you mentioned earlier, which it’s not clear when or even if they will be standardized in EcmaScript and then finally reach TypeScript.

the future of Rescript, I believe, depends heavily on the community,

The community seems to be on board, and there is exciting innovation going on in this scrappy little project. It’s good to keep in mind that ReScript hasn’t hired the guy (with a rumoured $1m+ signing bonus) who designed Turbo Pascal, Borland Delphi, and C#. Having said that, the ReScript team seems to be doing pretty well :wink:

8 Likes
3

Agreed! Which is why I’ve been very excited to see all the improvements that the community is working on. Be it better tooling in VS Code as well as major and minor improvements to the compiler and syntax to make it easier to write awesome JavaScript applications with ReScript.

I still believe ReScript’s major advantage over TypeScript is that its starting point is a sane type-system. Rather than trying to type all the intricacies of JavaScript that has spawned over the years. With that believe in mind I will thus also remain critical of initiatives where ReScript maybe tries to bend too much to JavaScript, rather than providing a great type-safe way to achieve the same thing with slightly less idiomatic JS. Though so far I think all initiatives are in-line with that philosophy which excites me a lot.

For me ReScript has proven itself when I build our Real-Time Chat over the period of 9 months (building both front-end and back-end on top of an existing application). Which has now been running in production for about a year. So far the tickets that have come in have been either feature requests or bugs around logic errors. No bugs caused by type errors.

That’s also why we’ve reaffirmed our choice to re-build our (currently coupled) front-end on ReScript, React and GraphQL and I’m (using this word a lot) very excited about it. :smiley:

4 Likes
4

I think it’s not right to compare TypeScript with ReScript. While the first might be only considered as a linter that developers can’t fully rely on, ReScript’s type-system will never let you shoot in your foot.

From TypeScript non-goals: “3. Apply a sound or “provably correct” type system. Instead, strike a balance between correctness and productivity.”

Also, by saying “JavaScript from the future” it’s not necessary that it should have some features that are currently ECMAScript proposals. What’s more important for me is that ReScript does not have some JavaScript features, that will never be possible to achieve in future JavaScript, because of backward compitability.
The most noticeable example is that ReScript doesn’t have classes.

Not having some features sometimes even better than having them. Because limitations can help us “To Fall Into The Pit of Success”

And some nitpicks :smile:

ReScript doesn’t have decorators, because as I mentioned before there’s no classes.

This feature will probably never be released, because it’s ether adds yet another comments syntax that doesn’t bring any value to JavaScript, or completely breaks web.

2 Likes
5

I believe it has nothing wrong to compare with a competitor, the same way Rescript is compared to plain JavaScript

I can understand why there are no classes, i’m aware of some ideas talked here: Haskell: OOP vs Type Classes.
Even though JavaScript ES5 Classes are just sugar syntax, at the end it’s just the same prototype chain, but it breaks Hindley-Milner because it does not support sub-typing, that’s why some languages that support classes like Typescript and Scala do not have it.

6

I believe what can make a language usable and pleasant are the foundational design principles that the language implements and how well it adheres to them. Renowned personalities and companies had nothing to do with the value of a language. Also keep in mind, that the functional programming principles followed by languages are free, ready to be embraced, without hiring any guy, people already worked on them, and gave them to all of us.

Rescript is also likely to embrace the Haskell motto:

avoid success at all costs

for a while, IYKWIM.

1 Like
7

That’s fine but at the end of the day, pretty much everyone involved in making a good language is getting paid for their efforts :slight_smile:

  • Go: paid by Google
  • C#, TypeScript: Microsoft
  • Python: various employers
  • Rust: Amazon and others
  • JavaScript: Google (V8)

Etc.

It’s just good to keep in mind that the pace and volume of development will reflect the amount of budget that is poured into the project. That’s why the community-driven aspect is so important for smaller projects.

2 Likes
8

Of course, i agree having full time devs has a lot of quicker benefits. About the community, i believe many are willing to help but don’t have the expertise or free time. If that is the case, we may focus on small contributions instead, like making some tutorials or libraries, some prepared enough will do the big ones.

9

My focus now, when trying to convince TypeScript programmers to use ReScript, is on developer experience. I haven’t had a lot of luck talking about a better type system because TS is moving much faster in that area. I don’t think it’ll ever catch up completely to Hindley-Milner systems, but it’s offering way more flexibility while having a good chunk of the safety (in strict mode).

We use TypeScript on TinyMCE, and there are two things that annoy me pretty much every day after working on ReScript for a while:

  • It’s slow. A clean build of a codebase this size takes 60-90 seconds and don’t get me started on how long webpack dev server takes to start.
  • I grow tired of how much hand-holding TypeScript requires with the constant need to specify types. Check out our recent efforts to enable strict mode.
4 Likes
10

Personally, I’m concentrated on writing libraries for reliable REST apis. Rescript is a great language, but the ecosystem to use it on the backend has many places for improvements.

2 Likes
11

My impression from this community-lead approach is that quite a lot can be done by pooling together resources from several community members.
That said, it would not go very far without some activity to constantly unblock people so they can progress on what it is they are doing in the time they have available.
I think there’s probably the need to support one or two individuals so they can put enough focus on the day to day activities needed for this whole process to work.
Now, everybody is trying to solve the creator economy, and however much fun it could be to attempt to solve that problem, perhaps it makes sense at this stage to just organise something simple to support the activity going forward.

16 Likes