RE: Golang v2, they clearly said they will not do it and will double down on backwards compatibility with exceptions powered by env vars and/or CLI switches.

▲

9rx 7 months ago | parent | next [-]

Technically, Go v2 signified the transition away from Google control to the project being directed by the community. That happened several years ago. Go v2 is already here and has been for a long time. The stdlib is also at v2 now (e.g. math/rand/v2).

You must mean the language? They said that a language v2 (go2) is probably unnecessary – that any future additions could be added without breaking the existing language. I don't expect simple tagged unions would need to break anything. A v2 (or even v3, perhaps) stdlib would be necessary to take advantage, like the parent suggests, but that has never been ruled out and is already the status quo.

▲

packetlost 7 months ago | parent [-]

This was what I was referring to. The stdlib is what would need to see backwards-compatibility-breaking changes, not the language itself.

▲

pdimitar 7 months ago | parent [-]

I am not sure how would that work? F.ex. how would you introduce tagged unions and make the language 100% backwards-compatible... but not the stdlib?

I admit I have no idea.

▲

9rx 7 months ago | parent [-]

The stdlib would remain 100% backwards compatible, but the implication was that he would want to see certain existing features of the stdlib amended with modified versions that leverage the new tagged unions. He imagined that modification would necessitate v2 stdlib packages to maintain sensibility.

	▲	pdimitar 7 months ago \| parent [-]
		Oh. Silly me, I am ashamed for failing reading comprehension so badly. Thanks for clarifying, that makes sense.

▲

packetlost 7 months ago | parent | prev [-]

I'm fully aware of that.