It makes it clearer that generics are functions applied to types, I like it a lot. Gives Go a leg up on the path to dependent types!
Conversation
Step 1: get tagged unions.
1
2
It should already have them, tagged unions are compatible with the "Go philosophy" in every way I can think of... every language should have them though.
1
AFAIK the Powers That Be say that tagged unions don't bring much to interface types so they don't want them.
1
1
My first instinct is to say "but those aren't the same thing!" but if it's a feature-for-feature trade I'd happily give up interfaces for tagged unions. Can always use records with functions in them instead, they're not even that bad to use.
2
I thought the issue was more that they started out with the assumption that everything needed a default value. Anyway, that means it's hard to have a default for tagged unions (which should have given them a hint that defaults for everything is kinda ick, but egh).
2
1
It's not hard to have a default for tagged unions anyway, just make people specify one as the default (though why you insist on this I have no earthly idea).
2
1
I'm _guessing_ because they were coming from a C perspective and wanted to ensure everything was zero initialised to start off with because it was safer. And then a whole tower of design decisions were built atop that.
2
Where as a better solution is to ensure that things are always assigned a value on construction. That seems to give you much more room to move in the design space, and leads to less code that constructs things in invalid states (this is rampant from what I've seen).
1
1
There are some practical advantages to having a fixed initial value like zero... mostly related to allocator optimizations, AFAIK. But of course if those aren't actually reasonable values and always get changed in practice these optimizations are worthless.
2
1
Replying to
Yeah, I'm not sure if it's 'a fixed value' or just 'some default'. You might be right that there are optimization considerations built on top of there, but OCaml's pretty quick and it seems to do ok here... out of my depth here though 🤷♀️
Replying to
OCaml is a weird situation. Its GC is extremely optimized for some very specific kinds of programming (e.g. writing a Coq interpreter) and it requires considerable effort to beat it there. But many of its microoptimizations make language extension and compiler optimization hard.
2
2
Yeah, thanks for the nuance here - very appreciated. 👍
1