3 ms·

I think the best point in the article is this: > ReScript, as with other statically typed functional languages, aims at changing the way code is approached at

I think the best point in the article is this: > ReScript, as with other statically typed functional languages, aims at changing the way code is approached at a fundamental level. We currently have a project written in ReScript and it's an absolute nightmare. Most of our stack is JavaScript/TypeScript/Flow, so no one can just jump in and work on it very easily - they first have to learn ReScript and all of it's different concepts, approaches, and nuances (or refresh themselves if they've done that but haven't worked on the project in a while). It's a HUGE context switch. At least TypeScript is a superset of JavaScript so it's very easy to get up to speed on for a JavaScript developer, and switch between. For a side project this is fun. But I would never consider this for a "real-world" project (i.e. something you get paid for). At least not anytime soon. Maybe in a few years if there's wider adoption, but that's a long way off.

Cthulhu_ 6y ago
It's a common challenge with any kind of software; as a company, you want to avoid adding more to your stack, even if it means using a suboptimal or boring technology. Every new technology adds complexity and difficulty. Actually I'll just link it, it explains the concept much better (and with pictures!) than I can: http://boringtechnology.club/ http://boringtechnology.club/
- fxleach 6y ago
  TBH I'd stray from using TypeScript in your company stack as well, but I guess I'm just boring.
  - kiliancs 6y ago
    Nah, you just like risk.
  - jfengel 6y ago
    As somebody who really, really likes boring, I think it's time to put Typescript in the Boring category -- at least on the client side. Practically all major libraries provide a Typescript definition. Especially React, which has become the boring choice for a lot of client side programming. And you were going to end up using some sort of cross-compiler and packager for significant browser code anyway, just to wrap up all that risk about multiple browsers. That's a bit less clear on the server side, where you have more control. But two things are going for you: if you're going to use Node you might as well use the same language on both sides, and you can cleanly escape to plain Javascript if you feel compelled. (Personally I'd prefer a less sucky language, but honestly, TS makes JS pretty good. Not great, especially with all the legacy warts, but decent, and at least you get to share code with the browser.) TS has survived long enough and become endemic enough that it doesn't look like much risk any more, and it's a vastly better language than plain Javascript -- especially for reducing the risks that come with long-term boring projects. If you're writing JS and like boring, Typescript is looking increasingly like the good, boring choice.
chenglou 6y ago
I help maintain ReScript. That it _seems_ to change the way code is approached is an artifact of an early community excited to try FP concepts in it. Nothing wrong with that; however, the ReScript team (me included) don't really approach things this way. Our goal, outlined at (https://rescript-lang.org/docs/manual/latest/introduction https://rescript-lang.org/docs/manual/latest/introduction), is to provide: - a more solid type system - and a much faster compilation speed (a growing pain in TS projects) - to write mainstream code - for products (as opposed to a focus on intermediate FP libraries) The fact that it leverages some FP concepts here and there is just a mean, not the end. The marketing of this is really hard, because FP usually attracts the crowd you'd expect, at the expense of several of the above emphasis. But we're still working toward it. Having seen some ReScript codebases in the wild, I definitely know where your team comes from. We do try to approach it with the "different TypeScript" angle, but understandably userland doesn't always write code the way we'd like to recommend. In the spirit of https://news.ycombinator.com/item?id=25846479 https://news.ycombinator.com/item?id=25846479, we’re trying to become a boring technology. Unfortunately boring technology had to have gone through a hype period.

Cthulhu_ 6y ago

It's a common challenge with any kind of software; as a company, you want to avoid adding more to your stack, even if it means using a suboptimal or boring technology. Every new technology adds complexity and difficulty. Actually I'll just link it, it explains the concept much better (and with pictures!) than I can: http://boringtechnology.club/ http://boringtechnology.club/

fxleach 6y ago
TBH I'd stray from using TypeScript in your company stack as well, but I guess I'm just boring.
- kiliancs 6y ago
  Nah, you just like risk.
- jfengel 6y ago
  As somebody who really, really likes boring, I think it's time to put Typescript in the Boring category -- at least on the client side. Practically all major libraries provide a Typescript definition. Especially React, which has become the boring choice for a lot of client side programming. And you were going to end up using some sort of cross-compiler and packager for significant browser code anyway, just to wrap up all that risk about multiple browsers. That's a bit less clear on the server side, where you have more control. But two things are going for you: if you're going to use Node you might as well use the same language on both sides, and you can cleanly escape to plain Javascript if you feel compelled. (Personally I'd prefer a less sucky language, but honestly, TS makes JS pretty good. Not great, especially with all the legacy warts, but decent, and at least you get to share code with the browser.) TS has survived long enough and become endemic enough that it doesn't look like much risk any more, and it's a vastly better language than plain Javascript -- especially for reducing the risks that come with long-term boring projects. If you're writing JS and like boring, Typescript is looking increasingly like the good, boring choice.

chenglou 6y ago

I help maintain ReScript. That it _seems_ to change the way code is approached is an artifact of an early community excited to try FP concepts in it. Nothing wrong with that; however, the ReScript team (me included) don't really approach things this way. Our goal, outlined at (https://rescript-lang.org/docs/manual/latest/introduction https://rescript-lang.org/docs/manual/latest/introduction), is to provide: - a more solid type system - and a much faster compilation speed (a growing pain in TS projects) - to write mainstream code - for products (as opposed to a focus on intermediate FP libraries) The fact that it leverages some FP concepts here and there is just a mean, not the end. The marketing of this is really hard, because FP usually attracts the crowd you'd expect, at the expense of several of the above emphasis. But we're still working toward it. Having seen some ReScript codebases in the wild, I definitely know where your team comes from. We do try to approach it with the "different TypeScript" angle, but understandably userland doesn't always write code the way we'd like to recommend. In the spirit of https://news.ycombinator.com/item?id=25846479 https://news.ycombinator.com/item?id=25846479, we’re trying to become a boring technology. Unfortunately boring technology had to have gone through a hype period.