> TypeScript's type system is over-complex since it tries to be a superset of JS.
This is exactly why it got so popular, and TypeScript support in the JS ecosystem is so good. It's easy to just strip the TS metadata and you're left with working JS. This is why projects like esbuild managed to ship TS support so quickly (without type-checking).
Good luck doing that with a new language.
I for one am "all in" on TypeScript, with all its shortcomings it's just the best of both worlds, and so easy to get on board.
TypeScript's biggest flaw, IMO, is that it can't (or chooses not to- I don't understand anything about JS-adjacent build systems and how they work) understand the difference between "code I write" and "code someone else wrote".
I'm not going to beat the dead horse of how unsound TypeScript's type system is. We all know that most of that is intentional because it would just be too inconvenient to work with existing JavaScript code (Aside: think about what this implies about existing JavaScript code. This makes alarm bells go off in my head).
However, why should I have to deal with an unsound type system in my new, fresh, TypeScript-only code?
I'm not saying it's simple or criticizing anybody's work, but it would VASTLY increase my opinion of TypeScript if I could enable some kind of 'truly-strict-new-code' flag that would error on unsound code in the current project and maybe just warn when I call unsound code from a dependency.
Because, honestly, I'm truly disappointed that the one language that finally has a chance to unseat JavaScript has such a poor type system that it can't even do basic sub-type variance correctly no matter how many flags you set. Out of all of the statically typed languages I've used, TypeScript has helped me the least when it comes to type errors.
And it works in both directions. You can "easily" (I mean, this is JS afterall so this heavily depends on the degree of toolchain hell chosen) move to the TS toolchain and rename your files to have the .ts extension and you have a valid TS project and benefit from the inferred types for your code. Type annotations can then be added later on as you go. And the syntax everybody already knows stays valid.
This is a huge benefit compared to something like ReScript because it makes adoption really easy. With the obvious downside of not having nice features like pattern matching.
> It's easy to just strip the TS metadata and you're left with working JS.
Compared to what? JSDoc made it even easier, you didn't even need to strip anything, as the "types" were just comments. This comes with its own problems, who want to program with comments? But it didn't require any changes to use for us who want nothing to do with TS.
>It's easy to just strip the TS metadata and you're left with working JS.
This actually touches on one of ReScript's supposed unique selling points amongst the functional compile-to-JS languages. Namely that the JS its compiler generates is so clean and readable that, if you end up deciding you don't want to bother with ReScript any more, you can just take the output from the final time you ran the compiler and treat that as a plain JS codebase to continue working on. Exactly how true that is, I don't know.
In my experience with these typed alternatives to JS, as long as you stay within that language things are good and smooth. But as soon as you need to interface with 3rd part lib, that's when things start to get messy.
Providing type declarations for every third party lib you might want to use, especially in an ecosystem like Javascript's which relies heavily on them, gets tiring pretty fast.
Typescript manages to get past that because it has reached a level of adoption now that most popular libraries will have a @types/<lib> package also but it took a long while to reach that stage.
Curious if anyone has used ReScript at a larger scale (and does not have the resources of, say, Facebook) and what's their experience been like.
We use ReScript at Draftbit (https://draftbit.com). We're a small company with about 13 people.
Former coworkers have messaged me saying that they miss writing ReScript and wish they could convince their team.
We have about 1200 ReScript files on both front-end/back-end. It's great. It feels much safer to refactor and write new code.
We use TypeScript in some places, like TypeORM and we're able to consume those types on the Rescript side. Rescript generates and consumes typescript types via gentype.
I agree, ReScript has no big adoption (hopefully yet), and that's the biggest disadvantage in comparison with TypeScript.
But somebody has to do the first steps...
One solution is for the language to batteries-include all the most important stuff. This is pretty much what Elm does, and it seems like ReScript does at least some of that with the React integration
"This means having two files with the same name in different directories is not allowed."
"ReScript has no async/await support."
"ReScript has no special debugging support or source maps."
Sorry but aren't these issues fairly glaring problems? They're hand-waived away because the project is small, but I feel like they'd become quite major eventually?
The first one is a design decision that I consider a bit "meh" as well, but I can see why they did it. The third one I'm assuming is just a thing that hasn't been gotten around to, and I think is reasonable to not immediately expect from a smallish project.
The second one does sound like a fairly major thing though. The promise syntax shown in the article to get around the issue looks like a massive code smell.
* the use of decorators in even the most basic example
* no async/await. You fall back to Promise.{then,resolve}. The example given is not that clear to me.
* You can't have two files with the same name in different folders??
And in general, for me, the ability to be a little less strict at times makes Typescript way more easier to deal with. It's a 80/20 thing. Most of the time I want type enforced but in some situation, I know it's OK and I just want to move on with my day.
Using fp-ts there is never a need for async/await and the code is still linear, (Promise is transformed to TaskEither<Error, Result>, similar to the example in the article, although you can ignore the error and just map over the result, handling the error somewhere near the end of the chain).
Problem with async/await is that the syntax is so easy that eventually the whole codebase gets polluted by it, even parts that could have been completely separated.
From the coding perspective, the problem with promises arise when there is a need to bind the intermediate results. You can either store them in an object and return that object for the next .then(fn) call, or you can nest inside a promise. I guess nesting is what annoys people the most (pyramid).
There are a lot of stranger things typescript makes you do make things work properly =P
Rescript doesn't make you do strange things. The async/await stuff is annoying for sure, but after 3 years of using it, we've kinda forgotten about it.
> Unfortunately, today it's necessary to understand difference between OCaml, BuckleScript, Reason and ReScript to navigate in the ecosystem comfortably
I got hit by this literally yesterday. It took me a while to understand this mess.
Yup, that's a rough start.
I don't see how any project could take off with rebranding and splitting from an already small community, Reason users, (itself a split a relatively small community, Ocaml users).
It seems like the road to success is the other way around. Make it a little better while super easy to adopt and iterate on that à la TypeScript or Reason, which can be considered alternate syntaxes for Javascript and Ocaml users respectively and are super easy to adopt whereas forking Reason into yet another programming language that has no ecosystem/community and wait for it to grow is almost always the promise of a bad pain/benefits ratio.
Typescript is a gateway drug for Javascript programmers. It's backwards compatible. So, it's easy to get started. However, it comes with a lot of compromises to enable that backwards compatibility.
If you think of javascript as a compilation target rather than a language, typescript is just one of many languages that can target that. And I'd argue that even javascript these days is transpiled to what runs in the browser. It might be the same javascript dialect. But minified/obfuscated etc. But more commonly, it's more than just that. In short, modern javascript development involves transpilation/compilation. It just does. The whole scripted/interpreted vs. compiled distinction that people used to make is less relevant these days. It pretty much always involves some kind of compiler.
And if you are going to use a compiler, you might as well use a proper one that does some useful stuff like prevent bugs, check types, optimize, etc. Typesystems have come a long way in the last 20 years. In short, there is no technical reason to be using Javascript exclusively in 2022. Whether it's Clojure, Elm, Kotlin, or other languages; they each have in common that they have js transpilers that work quite nicely and type systems that are definitely a level up from the unholy mess that is Javascript's "it could be a string or some object or undefined, but who the hell knows". Some people actually prefer that. Other people want no part of that kind of sloppy typing. And the good news is that there is no technical need to have any of that.
I've been using Kotlin-js for the last year for a web application. The tool chain has some rough edges but the language is a joy to work with generally also for browser development. Definitely an upgrade over typescript, which I've also used in the past. And we have quite a bit of multi platform kotlin code that we also use server side. A lot of what we do is increasingly multiplatform and not explicitly dependent on the JVM. We could choose to use that code also on Android or IOS (via the native compiler). With compose web and other emerging Kotin web frameworks and the upcoming WASM compiler for Kotlin, I suspect it's going to become a lot more popular to use for web applications. With WASM, transpiling to Javascript will ultimately become a thing of the past. If you are compiling, you might as well produce WASM. Short term there are some open interoperability issues with browser APIs of course. However, nothing that can't be solved long term.
Have you had issues around the distribution size? I've been playing with building a kvision based app for the past year as a side project, and I can't get much lower than 2MB. I suppose I might try a "hello world" with compose web and see how that shakes out.
You might be interested in trying PureScript as well. It has good FFI support and as a consequence there exist wellmaintained bindings into react etc. It can also run on other backends beside javascript, which makes that you can use it for backend programming too.
Yes, out of all alternatives I looked at, I did choose PureScript because of the (relatively) easy JS interop (which Elm lacks), not needing the JVM and having types (Clojurescript) and the better async handling without the need of `then`s and the function 'pyramids' and, last, but not least, the lack of (C-) JS-Style syntax.
None of the available alternatives to typescript — Elm, Purescript, Reason/Rescript — give me the same feeling of confidence in the future direction of these projects as typescript does. At least typescript is very closely aligned with the development of javascript; and it's also very widely used.
- Elm: not general-purpose enough (only useful for UIs), plus has a tendency of making drastic changes between versions (remember how loudly people complained here? [0])
- Purescript: the designer of the language, Phil Freeman, has stepped away from this project, and it doesn't seem to have gained sufficient traction
- Rescript: I'm put off by its ocamlness; and worry whether it will repeat the trajectory of Flow, which has essentially become irrelevant
> Elm: not general-purpose enough (only useful for UIs), plus has a tendency of making drastic changes between versions (remember how loudly people complained here?
Not really, it just has a slow release schedule. Over time it is relatively stable.
Not a single thing has changed about it the last two years and the creator has communicated that it will probably stay mostly the same for quite a while.
Yes, there have been some bigger changes in the past but that is fair game for software that hasn't hit version 1 yet and it was communicated that it might happen.
The drama is mostly an issue caused by misaligned expectations: Many people assume that open source projects should be developed openly with everyone being able to contribute and having a say about the direction. Evan, the author of Elm, prefers to keep tight control of everything. The approach has some advantages and disadvantages and I can see why people might decide to stay away from the community but honestly if you just want to get work done in Elm, it is not much of an issue either way.
Elm is probably the most stable and reliable choice for frontend code and helps avoiding the churn that happens in the JS ecosystems.
Business logic can be shared with .NET and it has lots of ways to interoperate with JS. There's even a TypeScript converter though of course it's not as pleasant as "yarn add" and YMMV : https://fable.io/ts2fable/
> Despite requiring very verbose type annotations, TypeScript does not have a sound type system, meaning it does not guarantee the absence of type-related errors in runtime even if everything compiles fine.
Does ReScript solve that? If so, how? In my experience this is mostly an issue with data/functions coming from outside sources (Return values from HTTP calls to endpoints you don't control being a big culprit). Sure, you can write type definitions for that but that doesn't mean anything unless everything is manually validated/checked at runtime as nothing really guarantees that the type definitions are actually correct. Does ReScript handle that automatically?
That's not what soundness means in a type system. Of course untyped input has to be parsed and validated.
An unsound type system means that you can write code that compiles, but experiences a runtime error caused specifically by the types (not the values or the business logic conditions) not actually being compatible. The famous example is having an array of a subtype being used as an array of the supertype:
function doStuff(animals: Animal[]) {
animals.clear()
animals.push(new Cat())
}
const dogs: Dog[] = [new Dog()]
doStuff(dogs)
dogs[0].bark() // <-- type error
In a sound type system, that code would not compile because we know that you can't treat an array of Dog as an array of Animal in general.
There still "weak" points, where incorrect typing can be introduced, e.g. incorrectly written bindings.
Regarding data from HTTP call in theory they can be cast to any type abusing `external` keyword which is meant for binings.
But common and recommend approach is to write codes. Codec would perform all the necessary checks to ensure that the data are in correct shape to satisfy the type restrictions.
You can see some examples here: https://github.com/greyblake/from-typescript-to-rescript/blo...
I've used Rescript (and ReasonML before that) for side projects, I really like it. I'd say it main strength is also its main weaknesses; it's not JS with a C# sauce (like TS), it's OCaml'ish with a JS sauce, making it really nice in many ways but also harder to pick up for JS folks.
That's where Typescript clearly has the advantage; being just JS with types makes it much easier to get started, and the fact that its #huge also helps a lot.
It's a bit sad as I think ReScript is much better on many fronts: the type system with crazy good inference and soundness, very easy to configure and add to existing projects (it just outputs JS files even with TS types), the module system is amazing (gone with imports) and creating simple bindings to existing JS/TS is also quite easy once you understand the basics, I'd go as far as saying it's easier than TS . It's also really fast, both the compilation as well as the JS it outputs.
Because of the adoption hurtle I doubt it will be as big as TS, but I really hope it gains enough momentum and usage to just sit comfy in its niche, for that I think it needs to grow a bit further.
I do think the ReScript team has made incredible progress on all fronts; I think ReScript is much easier to pick up than Reason, because of the language tweaks, but also the new website is so much better than the scattered docs in multiple places.
I hope it will continue to improve and more people will give it a go!
I've been using ReScript for a few months now. So far I mostly like it, but it takes some time to get used to it. The error messages can be confusing though so I try not to depend too much on type inference. The other downside is that some bindings for some of the web apis seem to be missing (like for the types in the Dom module).
Btw, for Material UI there are already bindings [1]
As a sort of litmus test I use the number of stars a superset of(or language compiling to) JavaScript has on GitHub and how that compares to fartscroll.js: https://github.com/theonion/fartscroll.js/
By this measure ReScript is still a niche language.
> there was a type mismatch, but the error the compiler reported was quite far from the original error made by me. It's not a compiler's fault, the fault was purely mine.
I feel like the amount of time you would spend dealing with weird interop is far far greater than the number of times typescripts unsoundness would get you (hardly ever in my experience)
[+] [-] dsnr|4 years ago|reply
This is exactly why it got so popular, and TypeScript support in the JS ecosystem is so good. It's easy to just strip the TS metadata and you're left with working JS. This is why projects like esbuild managed to ship TS support so quickly (without type-checking). Good luck doing that with a new language.
I for one am "all in" on TypeScript, with all its shortcomings it's just the best of both worlds, and so easy to get on board.
[+] [-] ragnese|4 years ago|reply
I'm not going to beat the dead horse of how unsound TypeScript's type system is. We all know that most of that is intentional because it would just be too inconvenient to work with existing JavaScript code (Aside: think about what this implies about existing JavaScript code. This makes alarm bells go off in my head).
However, why should I have to deal with an unsound type system in my new, fresh, TypeScript-only code?
I'm not saying it's simple or criticizing anybody's work, but it would VASTLY increase my opinion of TypeScript if I could enable some kind of 'truly-strict-new-code' flag that would error on unsound code in the current project and maybe just warn when I call unsound code from a dependency.
Because, honestly, I'm truly disappointed that the one language that finally has a chance to unseat JavaScript has such a poor type system that it can't even do basic sub-type variance correctly no matter how many flags you set. Out of all of the statically typed languages I've used, TypeScript has helped me the least when it comes to type errors.
[+] [-] elevader|4 years ago|reply
[+] [-] capableweb|4 years ago|reply
Compared to what? JSDoc made it even easier, you didn't even need to strip anything, as the "types" were just comments. This comes with its own problems, who want to program with comments? But it didn't require any changes to use for us who want nothing to do with TS.
[+] [-] frou_dh|4 years ago|reply
This actually touches on one of ReScript's supposed unique selling points amongst the functional compile-to-JS languages. Namely that the JS its compiler generates is so clean and readable that, if you end up deciding you don't want to bother with ReScript any more, you can just take the output from the final time you ran the compiler and treat that as a plain JS codebase to continue working on. Exactly how true that is, I don't know.
[+] [-] thegreatpeter|4 years ago|reply
If you're "all in" on TypeScript, you'll love Rescript. It's sooo much faster. Been using it for 3 years now.
[+] [-] pjmlp|4 years ago|reply
[+] [-] jatins|4 years ago|reply
Providing type declarations for every third party lib you might want to use, especially in an ecosystem like Javascript's which relies heavily on them, gets tiring pretty fast.
Typescript manages to get past that because it has reached a level of adoption now that most popular libraries will have a @types/<lib> package also but it took a long while to reach that stage.
Curious if anyone has used ReScript at a larger scale (and does not have the resources of, say, Facebook) and what's their experience been like.
[+] [-] thegreatpeter|4 years ago|reply
Former coworkers have messaged me saying that they miss writing ReScript and wish they could convince their team.
We have about 1200 ReScript files on both front-end/back-end. It's great. It feels much safer to refactor and write new code.
We use TypeScript in some places, like TypeORM and we're able to consume those types on the Rescript side. Rescript generates and consumes typescript types via gentype.
I'd strongly recommend you try it!
[+] [-] idontwantthis|4 years ago|reply
If you need to add types to a JS library that still doesn’t have them for some reason, you’re actually doing less work than if you didn’t add them.
Add the types as needed and you’re good.
[+] [-] greyblake|4 years ago|reply
[+] [-] brundolf|4 years ago|reply
[+] [-] moritonal|4 years ago|reply
"ReScript has no async/await support."
"ReScript has no special debugging support or source maps."
Sorry but aren't these issues fairly glaring problems? They're hand-waived away because the project is small, but I feel like they'd become quite major eventually?
[+] [-] Deukhoofd|4 years ago|reply
The second one does sound like a fairly major thing though. The promise syntax shown in the article to get around the issue looks like a massive code smell.
[+] [-] skywal_l|4 years ago|reply
* the use of decorators in even the most basic example
* no async/await. You fall back to Promise.{then,resolve}. The example given is not that clear to me.
* You can't have two files with the same name in different folders??
And in general, for me, the ability to be a little less strict at times makes Typescript way more easier to deal with. It's a 80/20 thing. Most of the time I want type enforced but in some situation, I know it's OK and I just want to move on with my day.
[+] [-] knuthsat|4 years ago|reply
Using fp-ts there is never a need for async/await and the code is still linear, (Promise is transformed to TaskEither<Error, Result>, similar to the example in the article, although you can ignore the error and just map over the result, handling the error somewhere near the end of the chain).
Problem with async/await is that the syntax is so easy that eventually the whole codebase gets polluted by it, even parts that could have been completely separated.
From the coding perspective, the problem with promises arise when there is a need to bind the intermediate results. You can either store them in an object and return that object for the next .then(fn) call, or you can nest inside a promise. I guess nesting is what annoys people the most (pyramid).
[+] [-] greyblake|4 years ago|reply
Can we agree that JSX is not a valid JS? So decorators are required indeed to simulate "JSX magic"
> no async/await.
As I mentioned, it's not an really an issue (although I though it will be). At least from my experience.
> You can't have two files with the same name in different folders??
This sucks indeed :)
The problem that those 20% corrupt the value of another 80% :/
[+] [-] Asraelite|4 years ago|reply
Doesn't this mean we're basically back to callback hell? This was one of the primary criticisms of Node before async/await was introduced.
[+] [-] ronenlh|4 years ago|reply
ReScript requires a lot of commitment, as you have to completely rewrite each module to 100% comply with the type algorithm.
Typescript even transpiles when it encounters type errors.
[+] [-] thegreatpeter|4 years ago|reply
Rescript doesn't make you do strange things. The async/await stuff is annoying for sure, but after 3 years of using it, we've kinda forgotten about it.
[+] [-] shp0ngle|4 years ago|reply
I got hit by this literally yesterday. It took me a while to understand this mess.
[+] [-] cassepipe|4 years ago|reply
A more thorough explanation of the whole kerfuffle : https://ersin-akinci.medium.com/confused-about-rescript-resc...
[+] [-] jillesvangurp|4 years ago|reply
If you think of javascript as a compilation target rather than a language, typescript is just one of many languages that can target that. And I'd argue that even javascript these days is transpiled to what runs in the browser. It might be the same javascript dialect. But minified/obfuscated etc. But more commonly, it's more than just that. In short, modern javascript development involves transpilation/compilation. It just does. The whole scripted/interpreted vs. compiled distinction that people used to make is less relevant these days. It pretty much always involves some kind of compiler.
And if you are going to use a compiler, you might as well use a proper one that does some useful stuff like prevent bugs, check types, optimize, etc. Typesystems have come a long way in the last 20 years. In short, there is no technical reason to be using Javascript exclusively in 2022. Whether it's Clojure, Elm, Kotlin, or other languages; they each have in common that they have js transpilers that work quite nicely and type systems that are definitely a level up from the unholy mess that is Javascript's "it could be a string or some object or undefined, but who the hell knows". Some people actually prefer that. Other people want no part of that kind of sloppy typing. And the good news is that there is no technical need to have any of that.
I've been using Kotlin-js for the last year for a web application. The tool chain has some rough edges but the language is a joy to work with generally also for browser development. Definitely an upgrade over typescript, which I've also used in the past. And we have quite a bit of multi platform kotlin code that we also use server side. A lot of what we do is increasingly multiplatform and not explicitly dependent on the JVM. We could choose to use that code also on Android or IOS (via the native compiler). With compose web and other emerging Kotin web frameworks and the upcoming WASM compiler for Kotlin, I suspect it's going to become a lot more popular to use for web applications. With WASM, transpiling to Javascript will ultimately become a thing of the past. If you are compiling, you might as well produce WASM. Short term there are some open interoperability issues with browser APIs of course. However, nothing that can't be solved long term.
[+] [-] smallerfish|4 years ago|reply
[+] [-] greyblake|4 years ago|reply
[+] [-] ctenb|4 years ago|reply
[+] [-] fbn79|4 years ago|reply
[+] [-] ReleaseCandidat|4 years ago|reply
[+] [-] greyblake|4 years ago|reply
[+] [-] azangru|4 years ago|reply
- Elm: not general-purpose enough (only useful for UIs), plus has a tendency of making drastic changes between versions (remember how loudly people complained here? [0])
- Purescript: the designer of the language, Phil Freeman, has stepped away from this project, and it doesn't seem to have gained sufficient traction
- Rescript: I'm put off by its ocamlness; and worry whether it will repeat the trajectory of Flow, which has essentially become irrelevant
[0] - https://news.ycombinator.com/item?id=22821447
[+] [-] cardanome|4 years ago|reply
Not really, it just has a slow release schedule. Over time it is relatively stable.
Not a single thing has changed about it the last two years and the creator has communicated that it will probably stay mostly the same for quite a while.
Yes, there have been some bigger changes in the past but that is fair game for software that hasn't hit version 1 yet and it was communicated that it might happen.
The drama is mostly an issue caused by misaligned expectations: Many people assume that open source projects should be developed openly with everyone being able to contribute and having a say about the direction. Evan, the author of Elm, prefers to keep tight control of everything. The approach has some advantages and disadvantages and I can see why people might decide to stay away from the community but honestly if you just want to get work done in Elm, it is not much of an issue either way.
Elm is probably the most stable and reliable choice for frontend code and helps avoiding the churn that happens in the JS ecosystems.
[+] [-] metta2uall|4 years ago|reply
Business logic can be shared with .NET and it has lots of ways to interoperate with JS. There's even a TypeScript converter though of course it's not as pleasant as "yarn add" and YMMV : https://fable.io/ts2fable/
Here's a demo of building some React components in F#: https://www.youtube.com/watch?v=a6Ct3CM_lj4&t=860s
[+] [-] fbn79|4 years ago|reply
[+] [-] elevader|4 years ago|reply
Does ReScript solve that? If so, how? In my experience this is mostly an issue with data/functions coming from outside sources (Return values from HTTP calls to endpoints you don't control being a big culprit). Sure, you can write type definitions for that but that doesn't mean anything unless everything is manually validated/checked at runtime as nothing really guarantees that the type definitions are actually correct. Does ReScript handle that automatically?
[+] [-] ragnese|4 years ago|reply
An unsound type system means that you can write code that compiles, but experiences a runtime error caused specifically by the types (not the values or the business logic conditions) not actually being compatible. The famous example is having an array of a subtype being used as an array of the supertype:
function doStuff(animals: Animal[]) { animals.clear() animals.push(new Cat()) }
const dogs: Dog[] = [new Dog()]
doStuff(dogs)
dogs[0].bark() // <-- type error
In a sound type system, that code would not compile because we know that you can't treat an array of Dog as an array of Animal in general.
[+] [-] greyblake|4 years ago|reply
[+] [-] the_gipsy|4 years ago|reply
[+] [-] chrischen|4 years ago|reply
[+] [-] codeptualize|4 years ago|reply
That's where Typescript clearly has the advantage; being just JS with types makes it much easier to get started, and the fact that its #huge also helps a lot.
It's a bit sad as I think ReScript is much better on many fronts: the type system with crazy good inference and soundness, very easy to configure and add to existing projects (it just outputs JS files even with TS types), the module system is amazing (gone with imports) and creating simple bindings to existing JS/TS is also quite easy once you understand the basics, I'd go as far as saying it's easier than TS . It's also really fast, both the compilation as well as the JS it outputs.
Because of the adoption hurtle I doubt it will be as big as TS, but I really hope it gains enough momentum and usage to just sit comfy in its niche, for that I think it needs to grow a bit further.
I do think the ReScript team has made incredible progress on all fronts; I think ReScript is much easier to pick up than Reason, because of the language tweaks, but also the new website is so much better than the scattered docs in multiple places.
I hope it will continue to improve and more people will give it a go!
[+] [-] elcapitan|4 years ago|reply
A couple of years ago I looked into Reason and really liked it, but the toolchain wasn't going anywhere and it didn't see a lot of adaption back then.
[+] [-] asplake|4 years ago|reply
[+] [-] greyblake|4 years ago|reply
[+] [-] gdsdfe|4 years ago|reply
[+] [-] ronenlh|4 years ago|reply
There are useful comments in my (shameless plug) post about my same transition:
https://news.ycombinator.com/item?id=25845147
[+] [-] onox|4 years ago|reply
Btw, for Material UI there are already bindings [1]
[1] https://github.com/cca-io/rescript-material-ui
[+] [-] ostenning|4 years ago|reply
[+] [-] Tade0|4 years ago|reply
By this measure ReScript is still a niche language.
[+] [-] chrischen|4 years ago|reply
[+] [-] dmitriid|4 years ago|reply
No. No it's not. It's the compiler's fault.
[+] [-] overgard|4 years ago|reply