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

31–40 of 238 posts

Re: Generics aren't ready for Go

#31

Post by kuschku »

j16sdiz wrote: post #21
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)

So how do I make e.g. a TreeSet of something, put my elements in, and get them back out as the same type, without casting?

Re: Generics aren't ready for Go

#32

Post by spion »

> Go strikes me as one of the most conservative programming languages available today. It’s small and simple, and every detail is carefully thought out.

This article is wrong in many ways, but I thought I'd point out this particular one. There are many really weird warts in Go, in fact its about average in "wartiness". Here is one example https://dave.cheney.net/2017/08/09/typed-nils-in-go-2

Go biggest advantage isn't the language, its the decent documentation and standard library design. The language is a bit mediocre. I wish the Go community accepted this and moved on - a mediocre language with good documentation and well done standard library is still an acceptable contender since so many other languages get those two wrong.

Re: Generics aren't ready for Go

#33

Post by gok »

> The constraints imposed by the lack of generics (and other things Go lacks) breed creativity

Uhg such programming language Stockholm syndrome. You could apply this fallacy to any feature. The lack of modules and a performant garbage collector also bred creative solutions in previous Go releases, but that doesn't mean that adding those was a bad idea.

Re: Generics aren't ready for Go

#34

Post by pjmlp »

jstimpfle wrote: post #26
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…

You don't need to expose any internal details on other languages that make use of generics.

Even on C++ this is be eventually a thing of the past, after modules get finally adopted.

Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world.

Re: Generics aren't ready for Go

#35

Post by Insanity »

alexandercrohde wrote: post #13

I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.

I programmed in Java and Haskell and have made the switch to Go some time ago for my current position.

I don't miss them - it's just a different way of programming but I've not ran into a problem that I couldn't overcome because they are missing.

OTOH, I've shot myself in the foot quite a few times with Generics.

Honestly, just _try_ it for longer than an exploratory session. Try to build something big with it, and see if you still miss it.

Re: Generics aren't ready for Go

#36

Post by heavenlyblue »

emersion wrote: post #24
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.

>> his would kill the advantage that it's very hard to write obscure Go code.

But it's very easy to spread that Go code into tens of Kloc.

The amount of error handling and if constructs make me feel as if I am readying assembly: predictable AF, but it doesn't help because the volume of the code is huge.

Re: Generics aren't ready for Go

#37

Post by emersion »

kasey_junk wrote: post #28
emersion wrote: post #16

Earlier quoted context omitted.

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

What's wrong with that? Go has channels thus it doesn't need futures/promises.

Re: Generics aren't ready for Go

#38

Post by jstimpfle »

andy_ppp wrote: post #19
alexandercrohde wrote: post #13

I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.

It's because Go is a brutalist hipster language - simplicity above utility. Forget a lack of generics, you don't even get proper error messages.

Is "hipster" a label you would like to apply to e.g. Russ Cox? Maybe the designers of Go have design goals that are different than what you have in mind. Maybe they don't see it as "simplicity vs utility", but more as "utility through simplicity".

Re: Generics aren't ready for Go

#39

Post by louthy »

u320 wrote: post #8

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

I agree. C# still has the legacy of its pre-generics era. It's not super-bad, but it still hangs around like a bad smell. If it ever gets higher-kinds then the current implementation of monadic types with the hacky extension methods will also hang around like a bad smell.

It seems crazy to me that language designers of modern statically typed languages wouldn't go for the state-of-the-art. I see the comments about simpilicty, but generics makes [working with abstract types] simpler (in my humble opinion, of course).

Re: Generics aren't ready for Go

#40

Post by emersion »

heavenlyblue wrote: post #30
emersion wrote: post #16

Earlier quoted context omitted.

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

Each code in each goroutine is synchronous. That's what makes it simpler than callbacks.
Post reply on HN