[knocte]

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

[nycdotnet]

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.

[pkilgore]

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]

how do you know?

[alpinisme]

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]

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

[c-hendricks]

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]

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]

You can enable null safety in TypeScript, seems like a pretty good fix to me.

[phplovesong]

Its mediocre at best. Like in maths, how would i feel if addition would sometime actully be division. Thats hiw bad it is.

[sabedevops]

Well, isn’t division just substractive addition?

[knocte]

Where did we lose you? we're talking about two flavours of null, not one.

[smt88]

How would TS fix null in JS without violating its core principles of adhering to EcmaScript standards and being a superset of JS?

[knocte]

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]

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.

[euroderf]

"A typed nil pointer is not a nil pointer."