TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe. When a type system has this property, it is said to not be “sound”.
Has no pitfalls, aka the type system is "sound" (the types will always be correct). E.g. If a type isn't marked as nullable, its value will never lie and let through some undefined value silently. ReScript code has no null/undefined errors.
Also check out Hegel - a static type-checker for JS that attempts to achieve soundness, which also enables far more powerful inference.
Obviously, this project is new, and has to basically "start over" on many of the things that TS added over the years. To avoid that, they do try to leverage existing .d.ts files, but this only seems to work for the most basic type-definitions right now, and man do they have their work cut out for them.
Still, this is definitely worth a look - I would strongly encourage anyone to at least spend 20 minutes poking around in the online playground to see what this is about. If you don't already know something like Elm or ReScript, you will be surprised by the safety you get from sound type-checking, and with a much smaller amount of manually type-hinting compared with TS.
This project is so overlooked, and really deserves a lot more attention than it gets. I think maybe some people are already fatigued by the constant growing complexity of TS, and my own early reaction was something like "ugh, another type-checker?" - but this really is a whole different ball game. Don't skip this one! 🙂
(i.e. Hegel is a tool rather than a language) it seems that comment syntax should be a "rather sooner than later" feature
to mitigate the risk of adoption
to make potentially lengthy type checking passes optional for regular red-green-refactor cycles. While this may sound weird from the static typing perspective this is what seems to be driving JSDoc TS adoption (TypeScript as a tool rather than a language or compiler).
Look, given how the JavaScript ecosystem works (i.e. tendency to be heavy on external dependencies) it's not all sunshine and roses in the ReScript world because JavaScript Interop is a topic in and onto itself.
I still believe that TypeScript adoption has less to do with the sincere desire (or need) to adopt static typing but more with VS Code's TypeScript support and the associated developer experience.
TypeScript knowingly limited the "type safety" potential by basing its syntax on JavaScript (prioritizing JavaScript interoperability) but then promptly introduced its own non-compatible syntax requiring transpilation.
At this point one cannot get around TypeScript. However I think it's a good idea to get familiar with JSDoc TypeScript. That way one can choose to author in JavaScript, not having to transpile all the time but simply run TypeScript occasionally as a super-linter.
Rich Harris
@rich_harris
Moved some of my smaller libs to JSDoc TS; thoroughly recommend it. Among other things, the resulting code is generally smaller than transpiled code. Building, testing etc all become much less finicky. And .d.ts files are still generated from source code twitter.com/swyx/status/13…
Interesting counter-trend - maintainers of large open source projects like @Sveltejs and @Deno_land are moving *AWAY* from writing their internals in TypeScript
Just at the same time when the wider dev world is falling in love with TS.
Reasons: build times and code complexity. https://t.co/a74GAoYhwp
Personally I still view TypeScript as a missed opportunity. Given the cost of compilation (and having to learn additional syntax) there was a real opportunity to use modern static typing (e.g. Rust vs C/C++).
TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web.
Microsoft introduced F# in 2005 and TypeScript didn't appear until 7 years later in 2012 - but ultimately the C# way of working and thinking prevaled (given that JavaScript dates back to 1995 I don't see 17 years worth of improvement in TypeScript).
@Rich_Harris@antony@swyx@sveltejs@deno_land It surprises me this requires convincing. TS is fully authortime convenience and really only obfuscates at runtime which isn't beneficial. (Non standard syntax aesthetics aside.)
Rescript has a lot of other syntax changes that go along with it, many of them opinionated at that. There's enough differences beyond just Typing that prevent me from ever wanting to use it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just know that TypeScript doesn't have your back as much as other options:
A Note on Soundness
Compare with Rescript:
Also check out Hegel - a static type-checker for JS that attempts to achieve soundness, which also enables far more powerful inference.
Obviously, this project is new, and has to basically "start over" on many of the things that TS added over the years. To avoid that, they do try to leverage existing
.d.tsfiles, but this only seems to work for the most basic type-definitions right now, and man do they have their work cut out for them.Still, this is definitely worth a look - I would strongly encourage anyone to at least spend 20 minutes poking around in the online playground to see what this is about. If you don't already know something like Elm or ReScript, you will be surprised by the safety you get from sound type-checking, and with a much smaller amount of manually type-hinting compared with TS.
This project is so overlooked, and really deserves a lot more attention than it gets. I think maybe some people are already fatigued by the constant growing complexity of TS, and my own early reaction was something like "ugh, another type-checker?" - but this really is a whole different ball game. Don't skip this one! 🙂
Given
and
(i.e. Hegel is a tool rather than a language) it seems that comment syntax should be a "rather sooner than later" feature
Hmmm... Thanks for the heads up.. I think i need to get familiar with Rescript and check more about "soundness"
Look, given how the JavaScript ecosystem works (i.e. tendency to be heavy on external dependencies) it's not all sunshine and roses in the ReScript world because JavaScript Interop is a topic in and onto itself.
I still believe that TypeScript adoption has less to do with the sincere desire (or need) to adopt static typing but more with VS Code's TypeScript support and the associated developer experience.
TypeScript knowingly limited the "type safety" potential by basing its syntax on JavaScript (prioritizing JavaScript interoperability) but then promptly introduced its own non-compatible syntax requiring transpilation.
At this point one cannot get around TypeScript. However I think it's a good idea to get familiar with JSDoc TypeScript. That way one can choose to author in JavaScript, not having to transpile all the time but simply run TypeScript occasionally as a super-linter.
Personally I still view TypeScript as a missed opportunity. Given the cost of compilation (and having to learn additional syntax) there was a real opportunity to use modern static typing (e.g. Rust vs C/C++).
Quote
Microsoft introduced F# in 2005 and TypeScript didn't appear until 7 years later in 2012 - but ultimately the C# way of working and thinking prevaled (given that JavaScript dates back to 1995 I don't see 17 years worth of improvement in TypeScript).
See also Here is why you might NOT want to use TypeScript, The Trouble with TypeScript.
Rescript has a lot of other syntax changes that go along with it, many of them opinionated at that. There's enough differences beyond just Typing that prevent me from ever wanting to use it.