Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics aren't ready for Go

drewdevault.com

Post reply on HN
Print view View original

21–30 of 238 posts

Re: Generics aren't ready for Go

#21

Post by j16sdiz »

whatshisface wrote: post #2

Maybe 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 use an interface.

Golang use duck typing. It is very flexible and very simple. (Some times too simple)

Re: Generics aren't ready for Go

#22

Post by vbezhenar »

pjmlp wrote: post #6
whatshisface wrote: post #2

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

Time for Go++?

Re: Generics aren't ready for Go

#23

Post by alexandercrohde »

This reads like sour grapes.

Basically, this is trying to spin "Popular language missing essential feature" into "But what if it's because they're braintstorming something EVEN BETTER???"

Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first.

Plus I think the language-obsession is usually cargo-culting and signaling. All good engineers I know use and enjoy several languages. The hipster/all-talk/buzzword engineers are the ones who insist on prototyping garbage in a new language every 6 weeks and dropping it entirely thereafter.

Re: Generics aren't ready for Go

#24

Post by emersion »

andy_ppp wrote: post #15

I keep thinking they could add macros instead but I guess the C++ version is too much history for them to be associated with. It would basically be like code generation at compile time, except much cleaner than the current, version-specific mess of tools.

Macros are another can of worms. Even if they're AST-aware like in Rust, you can do very complicated stuff with them and they are very hard to read/write/debug. This would kill the advantage that it's very hard to write obscure Go code.

Re: Generics aren't ready for Go

#25

Post by j16sdiz »

kasey_junk wrote: post #10
whatshisface wrote: post #2

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

use channel + goroutinue for that.

Goroutinue are very light weight. Zero size channel works like promise

Re: Generics aren't ready for Go

#26

Post by jstimpfle »

whatshisface wrote: post #2

Maybe 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?

Go has a kind of generics that also maps cleanly to machine-level generics: interface{}, which is like void* in C.

Whereas all the other kinds of generics, I believe, can't offer this quality. They require a lot of machine code instanciations (like C++'s template system). Or at least, in the case of virtual functions ("dynamic polymorphism" with VTables), they cause more brittle abstraction boundaries. Think how in C++, when definining a class, you need to expose a lot of internal details in the header file -- list all the private member functions and fields, etc. This has lead to the so-called PIMPL idiom which is exactly what you do in Go or C.

Re: Generics aren't ready for Go

#27

Post by pjmlp »

vbezhenar wrote: post #22
pjmlp wrote: post #6

Earlier quoted context omitted.

They make use of code generation like early MS-DOS C++ compilers, check Kubernetes source code.

Time for Go++?

Not at all, generics like CLU (1975) does, would already be better than the current state.

http://www.pmg.lcs.mit.edu/CLU.html

Re: Generics aren't ready for Go

#28

Post by kasey_junk »

emersion wrote: post #16
kasey_junk wrote: post #10

Earlier quoted context omitted.

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.

>Some that burn me a lot is support for future/promises This doesn't make sense in Go. Nothing is asynchronous in Go, everything is blocking. You use goroutines to execute multiple tasks at the same time. That's a big part of what makes Go simple: it's a lot easier to understand sequential code than spaghetti callbacks and promises (it's somewhat similar to async/await in the JavaScript world).

Yet open up nearly any large golang codebase and you’ll find a channel being used to return a single answer response in the future.

Re: Generics aren't ready for Go

#29

Post by andy_ppp »

candiodari wrote: post #20
andy_ppp wrote: post #15

I keep thinking they could add macros instead but I guess the C++ version is too much history for them to be associated with. It would basically be like code generation at compile time, except much cleaner than the current, version-specific mess of tools.

They have macros. Sort of. Search "go generate".

It looks gross. Why not quote and unquote - it makes it so much easier to reason about...

Re: Generics aren't ready for Go

#30

Post by heavenlyblue »

emersion wrote: post #16
kasey_junk wrote: post #10

Earlier quoted context omitted.

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.

>Some that burn me a lot is support for future/promises This doesn't make sense in Go. Nothing is asynchronous in Go, everything is blocking. You use goroutines to execute multiple tasks at the same time. That's a big part of what makes Go simple: it's a lot easier to understand sequential code than spaghetti callbacks and promises (it's somewhat similar to async/await in the JavaScript world).

Yeah, and that's why Go code is a spaghetti of communicating via channels, rather than callbacks.
Post reply on HN