Sections in Article:
a) An introduction
b) Why was Go needed
c) Target Audience
d) Go’s strengths
e) Go’s weaknesses
f) Towards Go 2
g) Go’s design philosophy
h) How to get started
i) Who is using Go
I don't think the language designers were familiar with them or aware of their utility. I've also heard they weren't sure how ADTs would play out in a language that had zero values for every type. There's a proposal somewhere for ADTs (for Go2, not Go1), but ADTs apart from generics are of limited utility, I think. I can't speak to atoms since I don't know what they are.
I’m curious about what you mean with ADT apart from generics.
Go already has struct obviously ( product types) so all it would need is sum types, which is only a bit more elvolved than its current enums. Of course, you woulf need enum’s cases to be of different types, but at least from a user pov it doesn’t seem to involve generics, does it ?
Maybe, but I don't see why better days modeling should be more valid than better abstraction. I'm not even convinced ADTs let you model you're data better than Go's interfaces; they're just safer and more convenient (and maybe more performant depending on implementation). Also, the designers have been famously unclear about their stance on generics. They certainly seem reluctant to add them, but the a good chunk of the community wants them badly and the evidence that they're useful is (perhaps unsurprisingly) mounting. The language maintainers have also been unclear about how useful generics must be to merit inclusion in the language, making it seem like they don't really intend to add generics, but they're just entertaining a conversation about generics to parry accusations that they aren't listening to their community.
ADTs have been one of the great programming breakthroughs for me personally, when I realized how much structure and logic they can bring to a codebase despite their simplicity. One of the reasons I like Swift. They are sort of on their way into C++ and the more languages that support them, the better.
There are some questionable statements like "Since the code gets directly combined to machine code, therefore, the binaries become portable." Compiling to machine code like C does not lead to portability.
I thought Go programs can run on different machines supporting the same machine code because many (most, I don't know) Go programs are statically linked.
Right - they statically link which means that you typically don't have to worry about shared object dependencies when moving the binary around. You just have big binaries. If you use cgo (integration with C-code and C based libraries) then you are back to *.so versioning problems.
19 comments
[ 3.1 ms ] story [ 55.3 ms ] threadGo already has struct obviously ( product types) so all it would need is sum types, which is only a bit more elvolved than its current enums. Of course, you woulf need enum’s cases to be of different types, but at least from a user pov it doesn’t seem to involve generics, does it ?
ADTs on the other hand are ther to help you model your data better.
I thought Go programs can run on different machines supporting the same machine code because many (most, I don't know) Go programs are statically linked.
Precisely!