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

71–80 of 238 posts

Re: Generics aren't ready for Go

#71

Post by robmccoll »

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?

As many others have stated, there are options. In the linked list example, you could use:

- container/list.List which uses its own Element with internal pointers and interface{} for values

- write a type-specific implementation (not generic, but no runtime type assertion)

- write your own implementation using your own node / element interface type (maybe your list is generic to types that support io.Writer - generic for some use, but if you need access to specific types, you're back to runtime type assertions)

- write your own interface{} implementation (constantly needs runtime type assertions)

- use code generation (maintenance is harder, potentially non-standard tooling / build steps, but hey - no runtime type assertions)

- use a slice instead of a list (Go's version of vectors / dynamic arrays) - still requires some implementation, but the language has a lot of built-ins that make this easier. Depends on use. If you are doing a lot of insertions in the middle, this may suck, FIFO may suck and you need to be careful about not doing append()-shift and effectively leaking memory, LIFO this is dynamic and gives you good cache locality. Up shot is no-runtime type stuff and at least the slices themselves and the built-ins are generic.

Re: Generics aren't ready for Go

#72

Post by weberc2 »

aikah wrote: post #62
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.

I'd be disappointed if Go went for unions instead of full-on Rust-like enums, but I agree with your general point.

Re: Generics aren't ready for Go

#73

Post by rowanG077 »

grumpydba wrote: post #47
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…

> Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first. Yet people can write distributed databases, monitoring tools, dns/DHCP servers in go. ANd they deliver stable and performant solutions with thousands of institutional users. How come, if the basics are not solved?

That is a meaningless statement. You can do anything in (almost)any language that doesn't mean the basics are solved.

Re: Generics aren't ready for Go

#74

Post by Retra »

grumpydba wrote: post #47
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…

> Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first. Yet people can write distributed databases, monitoring tools, dns/DHCP servers in go. ANd they deliver stable and performant solutions with thousands of institutional users. How come, if the basics are not solved?

You're being ungenerous. The way they are using "basics" implies that they don't have the basics they expect to have for the problems they want to solve. The fact that someone else has the ability to solve other problems using the tool is irrelevant, and only highlights that you have different expectations.

Re: Generics aren't ready for Go

#75

Post by pjmlp »

jstimpfle wrote: post #45
pjmlp wrote: post #34

Earlier quoted context omitted.

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.

Layouts of separately compiled classes/structs must still be exposed to the compiler. You can't hide layouts away, they are part of the interface . With all the disadvantages that dependencies bring. > 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. I would be interested to kn…

Exposed to the compiler doesn't imply exposed to everyone else to see.

It is solvable by not sitting in an ivory tower using C++ and Java as the typical examples why Go won't get generics, and instead engage with generics friendly communities.

Re: Generics aren't ready for Go

#76

Post by [deleted] »

jstimpfle wrote: post #38
andy_ppp wrote: post #19

Earlier quoted context omitted.

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

[deleted]

Re: Generics aren't ready for Go

#77

Post by aikah »

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

This isn't a macro language. It relies on an external program that the developer needs to write himself at first place. "go generate" just facilitates the execution of a third party program. It does nothing more, and doesn't even do it automatically when compiling a program.

Re: Generics aren't ready for Go

#78

Post by weberc2 »

rebeccaskinner wrote: post #67
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.

To be clear, you use cheap type assertions to get a well-typed value back out. You can use expensive operations from the `reflect` library to do other things, but not to get a well-typed value back out.

Re: Generics aren't ready for Go

#79

Post by fauigerzigerk »

>Have you ever seen someone write something to the effect of “I would use Go, but I need generics”? Perhaps we can infer from this that many of the people who are pining after generics in Go are not, in fact, Go users.

This is the sort non-adhominem adhominem attack that makes these debates so tedious.

Obviously, someone deciding not to use Go for lack of generics after giving it a serious try would end up not being a Go user. Does that invalidate their opinion?

The logic of this argument is strikingly cult-like. Any criticism coming from non-adherents is automatically disregarded on the basis of it coming from non-adherents.

Re: Generics aren't ready for Go

#80

Post by alexandercrohde »

Insanity wrote: post #63
alexandercrohde wrote: post #49

Earlier quoted context omitted.

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…

I will probably never opt-into a language for the rest of my life that is not-hybrid (able to be functional or procedural).

Because hybrid is objectively better than only supporting one.

Post reply on HN