Is #ReScript the future of #javascipt? A typed subset of JavaScript.
#Typescript is great but not all love it.
From the docs: "ReScript is the language for folks who don't necessarily love JavaScript, but who still acknowledge its importance."
As much as I like #TypeScript, I think there's still plenty of innovation left in the world of compiles-to-JavaScript languages. We need something that feels broadly like JavaScript, but shaves away the corner cases, makes everything immutable by default, and just...flows...better. And #ReScript might well be that language. Let's find out...
Hey scripting folks! I'm trying to get started with rescript-react-native and I'm having a bit of trouble, so I put a hundred dollars on it.
Come take my money!
https://github.com/rescript-react-native/rescript-react-native/issues/827
thank you async await for saving me from #JavaScript callback hell
thank you #ReScript for saving me from typeless no-trail-of-what's-returning-what hell
I just followed a bunch of type errors and ended up with a beautiful chain of async calls that execute in the proper order it's so cute
@rauschma What is your opinion of #ReScript (https://rescript-lang.org/)? It has somewhat an #OCaml heritage via #ReasonML
Edit: Just looked at the source for Grain; it’s mostly ReasonML!
So basically, it looks like the best way would be to:
1. Declare DTO types with *all* the fields (maybe using combining types if you use Rescript)
2. From these combined types, manually construct "entity" types. If needed, you can use composition (through records, tuples, etc) to combine multiple entities together.
2. OCaml has proper OOP, with inheritance, method overrides, all that stuff. But, unlike records, it's not easy to bind to JS objects, I think.
3. Somewhere on Rescript forum I saw something like "prefer explicitness to DRY". Which I guess makes sense?
What I think about it after some digging and poking around Melange and Rescript playgrounds:
1. Rescript can "combine" both object types and record types. If you have `type t1` and `type t2`, a `type t = {...t1, ...t2}` will have fields from both t1 and t2. But you can't put a variable of `type t` where a `t1` or `t2` is expected. At least this doesn't work: https://tinyurl.com/yv7j24mj
I don't mind breaking changes from time to time, but they really should have fully implemented import maps and written detailed documentation on the main site about how to upgrade *before* deprecating es6-global.
A question about ReasonML/Rescript/OCaml on JS.
How do you deal with the lack of structure inheritance?
I'm mainly a backend dev with OOP background so I'm probably not seeing something.
But at work, our frontend has a lot of types (TS) like this:
```
type Client = BaseClient & {
assignees: Actor[]
}
```
We use these for types that we get from API (a base type + some additional fields).
How would you model something like that in Reason/Rescript/OCaml?
I am adding the #ReScript language server to #nixpkgs. 
this PR to get it merged https://github.com/NixOS/nixpkgs/pull/348121
Hey, #Nix friends! I am working on making my first contribution to #nixpkgs, and I have a question:
The package I'm working on adding is an executable npm package, specifically the #ReScript language server.
I wouldn't mind taking on some responsibility for making sure that package is up to date, but it seems like the whole "maintainer" bit described here:
https://github.com/NixOS/nixpkgs/blob/master/maintainers/README.md#how-to-become-a-maintainer
...isn't actually applicable to npm packages b/c they're handled automatically. Do I have that right?
"ReScript: Rust like features for JavaScript - DEV Community" https://dev.to/jderochervlk/rescript-rust-like-features-for-javascript-27ig #rescript #javascript
If a #JavaScript #programmer is compelled to trade up to #TypeScript, then he ought to take one more step to #ReScript and, from thence, to #Reason. With Reason in hand, he wields the full power of #OCaml.
JavaScript → TypeScript → ReScript → Reason
During my parental leave I learned two new programming languages. One of them was #ReScript and I wrote up my impressions of it: https://snarky.ca/my-impressions-of-rescript/ .
At an emotional level, I adore #Python 3, #TypeScript 5, and #ReScript 11. But at an intellectual level, ....
Don't expect easy-to-fix bug in JS/TS while aiming to have smallest bundle size. It just too hard!
The worst part is closure compiler can't catch up with latest ES spec 
I place my hope on #ReScript but it doesn't emit sourcemap and there's no sign they're working on it 
Of late, there have been numerous good-hearted attempts at creating #webdev #DSL, both internal and external varieties. But just about every one of them get tripped up by the disjointed nature of the current web technologies and, soon, they degenerate into JavaScript mayhem.
When a #programming language obliges the #programmer to handcraft asynchronous communication, thread management, code-download splitting, server-side pre-rendering, session management, authentication, authorisation, transport encryption, data caching, data format conversion, content validation, message queues, storage optimisation, and myriad other system-level facilities, this language, by definition, is not a DSL.
At present, the only webdev DSL that I admire is #Elm, which is a Webskell. And I like #ReScript, not because it's in anyway a DSL, but because it's OCaml.
A different, but related, problem is this: modern business programmers confuse enterprise application implementation with systems programming. And modern business executives confuse enterprise application user interface with marketing material. This is ineffective and unproductive.
#rescript journey
So I need to create empty folder `node_modules/rescript/`to make `rescript-editor-analysis.exe` to works 
