11–20 of 327 posts
... and still no generics.
It is fairly clear by now that omitting generics is not an oversight, but rather a design choice. If you disagree, it sounds like Go isn't for you. Maybe it's time to just move on and ignore it instead of beating a dead horse. I am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how t…
I also write a little Go program every day as practice. If you want a sample of some Go. https://github.com/kris-s/daily-go
... and still no generics.
Actually, Ho has generics and has had them from the beginning. But they're only available for builtin types (slices, maps), not for user-defined types/functions.
Earlier quoted context omitted.
It is fairly clear by now that omitting generics is not an oversight, but rather a design choice. If you disagree, it sounds like Go isn't for you. Maybe it's time to just move on and ignore it instead of beating a dead horse. I am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how t…
The Go faq doesn't agree with you.
It is by design that Go does not have generics as the Go team have not found a design they feel works and they are unwilling to compromise the current design.
They may never.
I'd say after 6 years adoption rate has been rather lackluster
I picked up the new Go book (gopl.io) and have had a lot of fun going through it. The prevailing feeling of Go is "getting things done". I also write a little Go program every day as practice. If you want a sample of some Go. https://github.com/kris-s/daily-go
This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true.
I think a more accurate way to look at Go is that the language, tools, and standard library make decent design trade-offs when your target software is 1) simple 2) network daemon-y or a CLI and 3) going to be worked on by a wide variety of developers. There are lots of problems that fall into that problem set, and it is very nice to have a language targeted at it, but Go is certainly not a good fit for a huge number of software projects. You will be less productive in those cases using it.
Earlier quoted context omitted.
It is fairly clear by now that omitting generics is not an oversight, but rather a design choice. If you disagree, it sounds like Go isn't for you. Maybe it's time to just move on and ignore it instead of beating a dead horse. I am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how t…
The Go faq doesn't agree with you.
I'd say after 6 years adoption rate has been rather lackluster