Reason React 0.8

Post by dmit » Wed, May 13, 2020, 11:46 PM UTC

yawaramin wrote: post #30

dmit wrote: post #28

Earlier quoted context omitted.

To clarify, the link in 1) is where I took the number of changes from. And Re: 2) I have no doubt that Mr. Zhang knows what he's doing. I was just noting how even after the prodigious amount of work he has put into BS over the years, it is still falling behind JSOO which has the benefit of being more tightly bound to the parent OCaml project. I know about the different tradeoffs JSOO and BS have made. All I meant to…

There must be a misunderstanding here, maybe on my side, but I honestly can't see how BuckleScript is 'falling behind': it jumped from 4.02.3 to 4.06 fairly recently, with more upgrades planned, and there is ongoing work to make it emit JS that looks more and more hand-written. Its download count looks like hockey-stick growth: https://www.npmtrends.com/bs-platform Look, JSOO is great but it has a very different goal…

Post by Kaze404 » Thu, May 14, 2020, 12:00 AM UTC

yawaramin wrote: post #24

parhamn wrote: post #3

Earlier quoted context omitted.

Awesome! Question, say you use TypeScript already, what are the biggest tangible gains in terms of safety (measured by fewer bugs in production) you think can be achieved by using Reason?

- Full-fledged support for pattern-matching exhaustiveness check, not something you have to bake together using a 'tag' field. This means if you match on i.e. integers, the compiler will warn you if you don't include a catch-all default case. - Simple module system where you don't need to deal with named vs default imports and all the weird bugs getting them mixed up can bring - TypeScript's inherent JS-like nature c…

Post by yawaramin » Thu, May 14, 2020, 12:17 AM UTC

Kaze404 wrote: post #34

yawaramin wrote: post #24

Earlier quoted context omitted.

- Full-fledged support for pattern-matching exhaustiveness check, not something you have to bake together using a 'tag' field. This means if you match on i.e. integers, the compiler will warn you if you don't include a catch-all default case. - Simple module system where you don't need to deal with named vs default imports and all the weird bugs getting them mixed up can bring - TypeScript's inherent JS-like nature c…

> TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting to type a pair of parentheses FWIW this was just fixed in TypeScript 3.9.

Post by andrepd » Thu, May 14, 2020, 12:22 AM UTC

yawaramin wrote: post #21

_bxg1 wrote: post #15

Earlier quoted context omitted.

There's a difference between "the compiler is faster when run at the CLI" and "the language server is faster". A good language server remains responsive by doing quick, partial compilations on just the section that changed. A bad language server just wraps the standard compiler and re-runs the whole thing when a file is saved. The latter will eat up CPU/RAM and make for a frustrating dev experience, no matter how rel…

OCaml (the Reason compiler) has historically had excellent (and fast) editor support tooling: Merlin.[1] That is now being packaged up as a language server (i.e., LSP).[2] Once you try a Merlin-based editor addon, everything else will seem dog-slow. [1] https://github.com/ocaml/merlin [2] https://github.com/ocamllabs/vscode-ocaml-platform

Post by jordwalke » Thu, May 14, 2020, 12:25 AM UTC

dmit wrote: post #37

jordwalke wrote: post #35

Earlier quoted context omitted.

I believe it does address part of your comments. At the very least: "And then we have the ReasonML project that has seen even less activity recently" You comment seemed to be based on the assumption that the Reason syntax is the sum total of the Reason project, and I provided examples that would adjust that frame of reference. See the high level goal I mentioned - bring fast development, fast running, fully type safe…

Ah, you're right. I did judge the Reason project by the number of commits its main repo has seen in the past year. But surely you'll agree that "fast development, fast running, fully type safe programming" has been achieved years ago, and any incremental improvements coming from the BS project are just that - incremental.