6 ms·
Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be
by Veraticus 3y ago
Very insightful. Re: the generics point —
As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic.
I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functions. Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code.
Anyway. This was a good initial post and a good follow-up. Go is my favorite language out there right now for its clarity, power, and ease-of-use. And with loop variable capture coming (the biggest remaining foot gun in the language in my experience) the language is only getting better.
- jeswin 3y ago> power What power?
- Veraticus 3y agoThe power of voodoo
- icholy 3y ago> Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code. Who needs data structures right?
- Veraticus 3y agoUh, generics are not data structures and generics are neither the only way nor the best way to interact with data structures.
- lillywastaken 3y agoDo you think it is somehow more elegant to have a specialised version of a data-structure for every single type that may need to be placed into it? Or just to ignore the type whatsoever and erase it via interface{}? Even Golang's designers obviously realise that generics are a better way to interact with data structures because the standard types map and array were always "generic", just special cased as such.
- lenkite 3y agoYeah, you must hate use the golang map type then. It is a generic data-structure.
- rowanseymour 3y agoPrior to generics we relied heavily on dynamic typing via interface{}, for example: BulkInsert(db *sql.DB, objs []interface{}) This unfortunately meant that any time you had []Foo.. you had to allocate a new []interface{} and copy over the items. Now a function like that can look like: BulkInsert[T any](db *sql.DB, objs []T) And we're not wasting CPU cycles to copy the slice of []Foo. I'm struggling to see how that's code smell or less excellent than using []interface{} or duplicating the code for BulkInsert for every insertable type in our application.
- Veraticus 3y agoDynamic typing via interface{} is also huge Go code smell though, so... Generics are definitely better for you. But I would say the overall pattern you're employing of bulk inserting different kinds of data structures with one function is the problem. Of course, I don't know your code so I'm sure you have a good reason for choosing what you did, but a BulkInsert of Any certainly made me raise my eyebrow.
- rowanseymour 3y agoThe reason is the same reason that anyone ever writes a generic function (outside of writing a library) - to keep code DRY and avoid duplication. There is no upside to maintaining a large number of identical function implementations, and no scenario in which that is preferable to using generics.
- Veraticus 3y agoBut you probably will have to differentiate at some point between what you're inserting. Why not just do that, instead of artificially combine it into one function? Nevertheless I feel like I'm getting lost in the weeds of this example. Obviously DRY and less duplication is good. However, you have to strike a balance between being clever and being clear. And frankly I would prefer 3 lines of clear code to 1 line of hard-to-read code.
- 3y ago
- ilyt 3y ago> As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I guess you have never written a library. It's extremely useful there, stuff like "generic function that runs a channel thru X workers doing f() on it" is now easily possible with full type safety. > Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code. You can say that about literally any feature used by the incompetent. But overall yes, they are far more useful for writing libraries than actual applications
- Veraticus 3y agoI have written a library actually. I found interfaces perfectly sufficient for allowing applications to consume the contracts of the library without needing generics. Of course I understand that they have a use and are useful, but it's not like there weren't excellent solutions for this in Go before generics existed.
- Mesopropithecus 3y agoComments like this are why I like to joke that the G in Golang stands for gaslighting.
- Veraticus 3y agoDo you actually have anything of value to add to this discussion? Because this comment is pretty bad.
- Mesopropithecus 3y agoI have to apologize, I misread the context of "people whining..", which was in fact about those that don't even use the language. If this was not intended to be aggressive, sorry. Funny though that I did get triggered by it. Out of the Go community I've heard way too often "you don't really need xyz", when they mean "we're not going to support xyz, here's why, and if you disagree, we respectfully ask you to look elsewhere".
- wolfspaw 3y agoA PL without Generics is just Terrible DX for me, let me abstract the types in my Algorithms and Data Structures Goddammit! Now Golang is saved, with Generics it's actually an Awesome Incredible PL.
- soulbadguy 3y ago> Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code. I can't think of any other less confrontational way to say/ask , but beside GO which other language have you used ? Because the above statement is so far remove from my experiences and understand of programming that i suspect we don't we really use the same day to day tools/languages in general.