Hacker News: mort96

New comment by mort96 in "Upcoming breaking changes for npm v12"

mort96 — Wed, 10 Jun 2026 05:48:51 +0000

What exactly is it that's now retired that used to be deprecated? Isn't this just a collection of breaking changes to defaults?

New comment by mort96 in "Upcoming breaking changes for npm v12"

mort96 — Tue, 09 Jun 2026 22:45:31 +0000

Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?

New comment by mort96 in "Upcoming breaking changes for npm v12"

mort96 — Tue, 09 Jun 2026 21:56:00 +0000

Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell

New comment by mort96 in "Are you expected to run five Python type-checkers now?"

mort96 — Tue, 09 Jun 2026 08:26:44 +0000

The interpreter knows types at runtime, not at parse/compile time. The interpreter already does a lot of dynamic type checking. It has a much stricter type system than e.g JavaScript; JavaScript will pretty much always convert operands to produce some result (even if it's just NaN or the string "object Object"), while Python will often just give you a type error.

The interpreter doesn't know about static types.

I agree that they should've made typing more a proper part of the language and not left it in this weird half-defined state of "standard syntax and some standard typing imports but undefined semantics". But it's not just a matter of enforcing existing types.

New comment by mort96 in "Are you expected to run five Python type-checkers now?"

mort96 — Tue, 09 Jun 2026 08:12:57 +0000

I do think it is somewhat of an all or nothing thing. I can write dynamic languages, sure; I prefer having static types, but I have written a lot of dynamically typed code. However if I'm working in an editor with LSP integration, the experience is much worse when some things are missing types.

As an example, I may have a variable with types:

    const something = somelibrary.getSomething();

and I can type `something.` and see methods and properties. However, if my own code doesn't use types consistently, it's so easy to lose type info. For example:

    const something = someWrapper(someLibrary.getSomething())

or:

    function doSomethingWith(something) {
        ...
    }
    doSomethingWith(someLibrary.getSomething()

or any number of other patterns which accidentally strips type info from the variable if you don't use types everywhere.

I would much rather have a language where the compiler complains if some variable doesn't have a static type, than a language where I can accidentally leave something untyped. I don't understand which case I would want a variable or function to not have associated static type information.

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 22:01:03 +0000

I would say that pipes and shared memory are the IPC mechanisms? Controlling the state of the exec'd process's file descriptors would counts as a way to set up interprocess communication, but once that's done, it's the pipe or SHM that does the actual communication.

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 20:00:03 +0000

fork/exec is not an IPC model...

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 18:47:55 +0000

CoW is probably a good idea regardless, yeah. Overcommit is more questionable. Regardless, both ought to be argued based on their own merits. It's unfortunate that both are necessary as a consequence of fork().

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 18:43:45 +0000

"Faster IPC model" than what? Faster than writing to and reading from a pipe? Faster than POSIX shared memory?

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 18:42:10 +0000

anarazel's comment focuses entirely on performance, indicating that they have an impression that the discussion about why fork is bad is about performance. I'm not entirely sure where this impression came from, as it's not mentioned in rom1v's quote nor a point in the linked paper, "A fork() in the road".

New comment by mort96 in "The perils of UUID primary keys in SQLite"

mort96 — Sat, 06 Jun 2026 18:29:37 +0000

Yeah but now you have the world's biggest foot gun in your API.

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 18:07:46 +0000

What do you mean by consistency here?

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 17:31:47 +0000

Didn't I just say that "the problem with fork isn't really that it's slow"? It's all the other OS design choices it forces on you if you want it to be fast.

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 16:41:37 +0000

It says "(including memory)". It's pretty natural to read this as "(including the contents of allocated pages)".

New comment by mort96 in "Moving beyond fork() + exec()"

mort96 — Sat, 06 Jun 2026 16:39:53 +0000

The problem with fork isn't really that it's slow. The problem is that if you want it to be not-slow, it locks you into a bunch of OS design decisions: you more or less need a memory subsystem where all writable pages are refcounted and copy-on-write when the refcount is bigger than 1, and you need overcommit.

Now these decisions aren't objectively bad, but they have significant trade-offs and it's probably not a good idea that they're forced simply because we use fork()+exec() for process creation.

New comment by mort96 in "The perils of UUID primary keys in SQLite"

mort96 — Sat, 06 Jun 2026 14:20:07 +0000

Oh, that's much worse! The JSON string `{"a":9007199254740993}` decodes to the object `{"a":9007199254740992}` with typical JSON parsers like JavaScript's `JSON.parse`.

New comment by mort96 in "The perils of UUID primary keys in SQLite"

mort96 — Sat, 06 Jun 2026 10:27:23 +0000

And then you end up with strings on the other side, not numbers.

New comment by mort96 in "The perils of UUID primary keys in SQLite"

mort96 — Sat, 06 Jun 2026 10:26:36 +0000

Completely and utterly irrelevant.

New comment by mort96 in "The perils of UUID primary keys in SQLite"

mort96 — Sat, 06 Jun 2026 07:27:57 +0000

I hate this so much because you can’t nicely serialise a BigInt as JSON. Using a string is nicer but it only makes sense where int64 is used as an ID, not where it’s used as a number; and you don’t wanna have to configure this per field per query.

New comment by mort96 in "ESP32-S31"

mort96 — Wed, 03 Jun 2026 17:24:58 +0000

And even if you don't need WiFi + BLE for a particular project, you may need it for other projects, and it might have value for you to standardise on one ecosystem.