> below miner leaving rates.

What does this mean, sorry?

> the edge case collapse the entire system.

If you mean that if it reaches a certain point, the entire system will collapse, it means you don't understand the difficulty adjustment. If it's too expensive to mine, then some miners leave, which makes blocktimes be longer, but not to worry because the consequence of that it just that difficulty will go down, which means that you need less hashrate to mine (and maybe some of those miners that leave will come back because it is profitable again for them). This means that it is essentially impossible for all miners to leave at the same time; some of them stay even if at a loss, and some of them are just hobbyists that can already feed their miners with solar power (so there's really no loss for them in leaving them connected).

This makes sense but what if nobody get the system to the next checkpoint where the difficulty is allowed to go down?

Are there incentives for nodes to join the swarm (become a seeder)? If yes, how exactly, do they get paid in a decentralized way? Any URL where to get info about this?

its through the holepunch stack (i am the original creator). Incentives for sharing is through social incentives like in BitTorrent. If i use a model with my friends and family i can help rehost to them

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>

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.

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

how do you know?

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.

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

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.

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

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

Well, isn’t division just substractive addition?

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

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.

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.

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

With a small/minimalistic harness like Pi maybe it works well?

Exactly. Any github alternative needs to consume same GithubActions syntax OOTB I'm afraid.

Which, as far as I found so far, means Forgejo. Haven't found any others. And even Forgejo Actions says that it's mostly the same as Github Actions syntax, meaning you still have to double-check that everything still works the same. It probably will, but if you don't know what the corner cases are then you have to double-check everything. Still, it's probably the best migration option if you rely on GHA.

Gitea also, I think.

> On long distance trips I spend 1 hour charging for every 2 hours driving

In Spain, I take ~600km trips every once in a while. I just need to charge once in the middle of the trip, in a super-charger that is. And the charge is 25min maximum.

Your experience varies is basically opposite from my experience. Your situation is probably influenced, indeed, by the poor choice of EVs you purchased (range is the most important factor for me to buy) and the lack of superchargers around your area.

If an Ioniq 5 is a poor choice, I would love to know what a good choice is. Its energy usage is comparable to the vast majority of SUVs and it can charge at up to 227kW. The lack of good fast charger is certainly a difference compared to many areas.

Only the Long Range version of the Ioniq5 has decent range IMO. And BTW, the fact that it's an SUV is precisely a downside about it; smaller cars would have obviously more efficiency.

It's worth noting that at least EU vs US, most the the better quality EVs are not available. Almost all the long range and more efficient EVs are Chinese-made and are not available in the US. My understanding is that the vast majority of EVs in the EU are these Chinese-made ones because of their hugely superior performance.

I don't know if Canada has the same restrictions on EVs, and I definitely can't speak to longevity or quality of the Chinese-made EVs, only to the charging speed and range. BYD for example is one of these Chinese-made brands prohibited in the US but leading the industry in performance.

Or just run it in your VPS?

> Is Claude Code like this too? I wonder if Pi is any better.

I'm very happy with Pi myself (running it on a small VPS so that I don't need to do sandboxing shenanigans).

+1

So it's from the future? nice