
Beauty of the Go Programming Language - rayascott
https://hackernoon.com/the-beauty-of-go-98057e3f0a7d
======
noncoml
Anyone close to the development of Go knows why modern language features like
ADTs and atoms, which don’t really sacrifice simplicity, were left out?

~~~
weberc2
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.

~~~
bsaul
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 ?

~~~
weberc2
Generics make sum types more useful. For example, an option type rather than
int-option, string-option, etc.

~~~
noncoml
I think generics provide extra abstraction that Go designers want to avoid.

ADTs on the other hand are ther to help you model your data better.

~~~
weberc2
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.

------
snowAbstraction
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.

~~~
deadsy
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.

~~~
DrScump
You still have to worry about other factors such as byte-swapped platforms
(big- vs. little-endian).

------
dogruck
I enjoyed the summary, but also ended up simply jumping over to read the
official golang FAQ. Nice read though.

~~~
ainar-g
Link: [https://golang.org/doc/faq](https://golang.org/doc/faq)

------
axonic
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

