Join Nostr
2026-07-29 00:03:57 UTC
in reply to

mleku on Nostr: it is not even a fork, it is a deprecation. my main preferred programming language, ...

it is not even a fork, it is a deprecation.

my main preferred programming language, Go, has not bumped its major version

you can still compile code written in 2010, with almost no exceptions. while i think that Go needs to be improved on, the point i am making is that adding features is not a hard fork. old code still works. deprecated features can still work, though you can defensively modify the semantics to prevent the harm the original feature caused. the underlying implemwntation can even be changed if it does not change the semantics.

and deprecation can be enforced too. the code can be valid prior to a block height, but rejected later. the old blocks don't get rewritten. they are still valid and if the old rules allowed spending, they can be spent to a different type of utxo. the old one, or the old one with eg unrestricted witness push, can still now be invalid without any contradiction.

an example from Go is embed. previously you couldn't include arbitrary data as strings or bytes. you had to parse the data into code, into string or byte literals. you can still do that, but you wouldn't because it had limits, at some point the compiler blows up memory from ginormous strings or byte literals. you use embed now.

the old way at old scale is still valid, but you could now specify in Go that beyond a reasonable size, this literal data can become a compilation error. this can be fixed then by using a file and embed directive instead of an oversized kiteral.

same principle. it might be valid but it breaks reasonable limits and is obsolete. rewrite it with reasonable limits of, the node runners will say get off my lawn.

thhereis no justification for ordinals or bitvm. get off my lawn.