alt Hacker NewsFrom your blog entry:
> Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL
Thanks for raising this kind of things in such a comprehensible way.
Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem.
<selfPromotion>That's why I created my own Option type package in NPM in case it's useful for anyone: https://www.npmjs.com/package/fp-sdk </selfPromotion>
Replies
ReasonML / Melange / Rescript are a wholistic approach to this: The issue with stapling an option or result type into Typescript is that your colleagues and LLMs won't used it (ask me how I know).
You can enable null safety in TypeScript, seems like a pretty good fix to me.
Your readme would really benefit from code snippets illustrating the library. The context it currently contains is valuable but it’s more what I’d expect at the bottom of the readme as something more like historical context for why you wrote it.
"A typed nil pointer is not a nil pointer."
How would TS fix null in JS without violating its core principles of adhering to EcmaScript standards and being a superset of JS?
TypeScript tried to accurately model (and expose to language services) the actual behavior of JS with regards to null/undefined. In its early days, TypeScript got a lot of reflexive grief for attempting to make JS not JS. Had the TS team attempted to pave over null/undefined rather than modeling it with the best fidelity they could at the time, I think these criticisms would have been more on the mark.