5 ms·

From 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 thin

• smt88 6mo ago
  How would TS fix null in JS without violating its core principles of adhering to EcmaScript standards and being a superset of JS?
  • knocte 6mo ago
    Maybe spit warnings when undefined is used? In the same way it does for when you use typeScript in a type-loose way. But yeah it's a fair point. Sometimes I think I should just write my own lang (a subset of typescript), in the same fashion that Lisette dev has done.
    • smt88 5mo ago
      You can already do this with strict type checking enabled and the NonNullable type. You can't enforce it in any normal codebase because null is used extensively in the third party libraries you'll have to use for most projects.
• alpinisme 6mo ago
  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.
  • knocte 6mo ago
    Yup, in my TODO list (I've only recently published this package). For now you can just check the tests, or a SO answer I wrote a while ago (before I published the idea as an npm package): https://stackoverflow.com/a/78937127/544947 https://stackoverflow.com/a/78937127/544947
    • c-hendricks 5mo ago
      I still struggle to see the advantage of Option<T> in a language with null-safe accessors and unions function fnO(val?: number) { if (val == null) { return "NAH"; } else { return (val * val).toString(); } } test("testing Options", () => { let foo = undefined; let bar = 2; expect(fnO(foo)).toBe("NAH"); expect(fnO(bar)).toBe("4"); }); Your readme states > FP's languages approach of rather not having null at all But `None` is just another null / undefined, which brings along a bunch of non-idiomatic code around handling it.
      • knocte 5mo ago
        None is not just another nullish value. If you do a type check with None, and there is some value inside (so it is Some, not None), it is IMPOSSIBLE that the .value that you extract underneath is gone. This is an important race-condition that you might run into due to the nature of TS/JS, but by boxing the value with an immutable Option type, you're protected. Also this prevents people to run into NullReferenceException (or UndefinedRefsExceptions, or whatever is called in this ecosystem) for people that didn't turn strictNullChecks ON.
• symaxian 6mo ago
  You can enable null safety in TypeScript, seems like a pretty good fix to me.
  • knocte 6mo ago
    Where did we lose you? we're talking about two flavours of null, not one.
  • phplovesong 6mo ago
    Its mediocre at best. Like in maths, how would i feel if addition would sometime actully be division. Thats hiw bad it is.
    • sabedevops 5mo ago
      Well, isn’t division just substractive addition?
• euroderf 6mo ago
  "A typed nil pointer is not a nil pointer."
• pkilgore 6mo ago
  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).
  • knocte 6mo ago
    how do you know?
• nycdotnet 5mo ago
  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.