Generics aren't ready for Go
drewdevault.com
Generics aren't ready for Go
1–10 of 238 posts
Re: Generics aren't ready for Go
#2Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
Re: Generics aren't ready for Go
#3Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
My understanding is that the standard library containers implement generics via special compuler magic, and everyone else is using `interface {}`, which is the equivalent of a void point or "any" type in Go.
Re: Generics aren't ready for Go
#4Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
You'd have to use an equivalent of `void *` (for Go, it's the empty interface: `interface{}`). However in 99% of the cases the builtin slice and map data structures are enough.
Re: Generics aren't ready for Go
#5Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
I believe this is done using protocols / interfaces where you declare a shared api of the objects
Re: Generics aren't ready for Go
#6Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
They make use of code generation like early MS-DOS C++ compilers, check Kubernetes source code.
Re: Generics aren't ready for Go
#7Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
My understanding is that the standard library containers implement generics via special compuler magic, and everyone else is using `interface {}`, which is the equivalent of a void point or "any" type in Go.
It's not strictly speaking "standard library containers", but rather "builtin containers".
Re: Generics aren't ready for Go
#8This article highlights very well why designing a programming language without generics is a mistake. Adding it after the fact is not trivial, especially if you have high standards wrt simplicity and non-redundancy.
Re: Generics aren't ready for Go
#9Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
You generally try to design your list so it contains types with common methods by using an interface (not the any type interface{}, mind). You could have a list (slice or map) of io.Writer, where it can contain any type that implements Write([]byte) on itself.
Re: Generics aren't ready for Go
#10Maybe a Go programmer can enlighten me - without generics, how can you have data structures implementations that can contain more than one type? Do you have to have one linked list implementation for every type in your program? Do you have to abandon type checking by using an equivalent of void pointers? Or is the type system smart enough that you'd never need generics in the first place?
First go does have generics. It just doesn’t have user defined generics.
But to answer your question go has really mediocre support for a wide variety of problems. Some that burn me a lot is support for future/promises and support for modern lock free algorithms.
So you end up either writing non-optimal replacements, losing type safety or in some case code generation is used.