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

61–70 of 238 posts

Re: Generics aren't ready for Go

#61

Post by emersion »

spion wrote: post #32

> 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'…

There are some weird parts in the Go language, yes. But since it's so small, a lot fewer than other languages.

Re: Generics aren't ready for Go

#62

Post by aikah »

tebruno99 wrote: post #50

Been using Go for 4 years. I totally agree. It sucks to have to use your brain to think about alternative ideas on how to do something. However, I’ve come across much much better solutions to my problems than I would have if Go offered a crutch to my flawed thinking.

The problem is the solution is often to make the compiler ignore types all together and use interface {} wholesale, then test interfaces with type assertions.

If Go had a least unions, it would be a bit less painful to describe a range of finite types while keeping things strictly typed in functions and methods. Unions are a limited form of type polymorphism in a garbage collected language.

Re: Generics aren't ready for Go

#63

Post by Insanity »

alexandercrohde wrote: post #49
Insanity wrote: post #35

Earlier quoted context omitted.

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 s…

As a rule I don't learn "trendy" things until the fad period dies off (be it a netflix show, a product, an app, a diet, or a language). But basically lodash is my bread-and-butter. Could such a library even exist in a language without generics?

The question is, why _should_ such a thing exist in a language without generics? It's just a different programming paradigm.

Program into a language, don't program in a language.

The functional approach is just one way to solve the problem. Also, as a side-note, when I program at home I'll often take a functional language. It's just a different way of programming and I do like FP (Haskell mainly). But Go is different, not worse or better.

Re: Generics aren't ready for Go

#64

Post by alexandercrohde »

emersion wrote: post #55
alexandercrohde wrote: post #23

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…

>Popular language missing essential feature But is it an essential feature? I've written a lot of Go code and I'm perfectly fine without generics. It makes my code a lot simpler, no need to abstract everything into Thing >. By the way, C doesn't have generics. If you really need generics that badly for your use-case, nothing stops you from using another language.

I'm not super educated on this, but the example I'm asking is "How would you port the library lodash to your language without generics?"

Re: Generics aren't ready for Go

#65

Post by ben-schaaf »

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…

If void pointers are "generics" as you say, then the word is pretty much meaningless. Every language I know of supports that kind of construct and you can usually dump it everywhere as much as you like.

Generics specifically refer to the parameterization of types using types. Go doesn't have user defined generics.

The only reason in C++ why you need to define all the "internal details" in the header file is because the compiler needs to know the size of things. You can write completely template free code that requires all your classes to be defined in headers or you can litter your code with templates, put pointers everywhere and place all your classes outside of headers. It has nothing to do with generics and everything to do with how the rest of C++ is designed.

Re: Generics aren't ready for Go

#66

Post by emersion »

gok wrote: post #33

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

As said in the article, solutions to these problems have now been implemented. These solutions _feel_ very Go-ish. Modules are an elegant solution. Adding them was a good idea.

Until we find an elegant solution for the generics issue, it's better not to have them.

Re: Generics aren't ready for Go

#67

Post by rebeccaskinner »

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?

Interfaces help a little bit. You can't really build re-usable data structures without falling back to `interface{}` and then incurring a performance hit from using reflection to get a well-typed value back out; but you can at least make your bespoke structures very marginally more reusable by defining interfaces ad-hoc.

Re: Generics aren't ready for Go

#68

Post by weberc2 »

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.

What a bizarre criticism... If anything Go is a ruthlessly utilitarian language; utility above mathematical elegance. I say this as someone who values mathematical elegance. If I want mathematical elegance, I reach for a functional language; if I want to get something done, I reach (sometimes begrudgingly) for Go (and occassionally Python or JavaScript/TypeScript).

Re: Generics aren't ready for Go

#69

Post by aikah »

dana321 wrote: post #17
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.

using interface{} and reflect is good enough for the many problems of using X datatype

No it is not. What's the point of a compiler if you check types at runtime? It's just that a lot of things in Go weren't carefully designed and now the price of adding something to the language is the price of dealing with technical debt. For instance Go has a form of exception (panics), returning errors is purely a convention. But panics aren't very good at exceptions either.

Re: Generics aren't ready for Go

#70

Post by norswap »

emersion wrote: post #55
alexandercrohde wrote: post #23

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…

>Popular language missing essential feature But is it an essential feature? I've written a lot of Go code and I'm perfectly fine without generics. It makes my code a lot simpler, no need to abstract everything into Thing >. By the way, C doesn't have generics. If you really need generics that badly for your use-case, nothing stops you from using another language.

If you nitpick enough, nothing is essential. We can write everything in C, or heck, even assembly.

"If you're not happy go look elsewhere" doesn't move the needle on the question "Should Go have generic" at all. It's not an argument at all.

Post reply on HN