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

111–120 of 238 posts

Re: Generics aren't ready for Go

#111

Post by aikah »

dana321 wrote: post #104
aikah wrote: post #69

Earlier quoted context omitted.

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.

Well, what was the point of adding std::any in C++17? Generics aren't a cure-all, they merely duplicate code and change the type. Its not much better than copy-paste and replace the type names.

> Generics aren't a cure-all, they merely duplicate code and change the type. Its not much better than copy-paste and replace the type names.

Nobody ever said that.

> . Its not much better than copy-paste and replace the type names.

Yes it is. You let the compiler do the job, instead of doing it manually.

Re: Generics aren't ready for Go

#112

Post by louthy »

bunderbunder wrote: post #99
bunderbunder wrote: post #95

Earlier quoted context omitted.

Yeah, sorry if I wasn't being clear. That's pretty much the line I was thinking along. It's perfectly fine for Go's answer to be, "Go doesn't have generics because generics aren't needed to solve the kinds of problems Go is designed for solving, and we are not trying to be a kitchen sink language here. If generics are something you need, please pick a language that's designed to solve the problems that you're trying…

Or, to throw a third option one out there -- "Go doesn't have generics because they would interact poorly with some other aspect of the language." That works, too. For example, it's why F# continues not to have ad-hoc polymorphism, despite many users clamoring for it. I'm inclined to agree with the project's maintainers on the subject. As useful a thing as it is, and as glaring as it is for a modern descendant of ML…

Both F# and C# can do ad-hoc polymorphism - I use it in my language-ext library [1], the library is C# but the principle is the same for F#. It's not idiomatic (or pretty), but it's possible if needed. Higher-kinds is the killer missing feature.

[1] https://github.com/louthy/language-ext#ad-hoc-polymorphism

Re: Generics aren't ready for Go

#113

Post by jstimpfle »

andy_ppp wrote: post #101
jstimpfle wrote: post #38

Earlier quoted context omitted.

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

"Hipster: A person who follows the latest trends and fashions, especially those regarded as being outside the cultural mainstream ." Yep. Go is a hipster language, even if you don't like it.

"The latest trends"? To me Go is particularly conservative.

I don't feel like arguing over a word that has become essentially meaningless over time, but I think you have seriously misunderstood what hipster means or was once supposed to mean. Either that, or you don't really know about Go and are just judging it by its marketing's design aesthetics (Gopher, fonts etc. following a trendy googley style).

Re: Generics aren't ready for Go

#114

Post by weberc2 »

alexandercrohde wrote: post #64
emersion wrote: post #55

Earlier quoted context omitted.

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

"Porting lodash" isn't an end unto itself, but you can use `interface{}` everywhere and have the same degree of type safety that lodash enjoys, which is to say zero.

Re: Generics aren't ready for Go

#115

Post by jstimpfle »

weberc2 wrote: post #68
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.

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

I even think that this utility (to me, it is synonymous with the simplicity from which it comes) has actual mathematical elegance. Whereas functional languages I find not particularly elegant once they hit the real world, must run on real machines etc. It gets ugly, complicated, or slow, really quick.

Re: Generics aren't ready for Go

#116

Post by weberc2 »

rowanG077 wrote: post #73
grumpydba wrote: post #47

Earlier quoted context omitted.

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

The parent should have said, "Go is regularly used to ship..." instead of "Go can be used...". The fact that Go backs all sorts of complex, interesting software testifies that it has solved the basics extrememly well, and if you're going to argue for a definition of "the basics" which doesn't respect shipping software then your argument is self-defeating. "Generics" isn't an end unto itself, after all.

Re: Generics aren't ready for Go

#117

Post by grumpydba »

pjmlp wrote: post #84
grumpydba wrote: post #47

Earlier quoted context omitted.

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

I used to write full blown applications in Assembly as well.

With thousands of institutional users? Implementing distributed databases?

Re: Generics aren't ready for Go

#118

Post by dana321 »

aikah wrote: post #111
dana321 wrote: post #104

Earlier quoted context omitted.

Well, what was the point of adding std::any in C++17? Generics aren't a cure-all, they merely duplicate code and change the type. Its not much better than copy-paste and replace the type names.

> Generics aren't a cure-all, they merely duplicate code and change the type. Its not much better than copy-paste and replace the type names. Nobody ever said that. > . Its not much better than copy-paste and replace the type names. Yes it is. You let the compiler do the job, instead of doing it manually.

Ok, well i just said it, so somebody did.

There is no difference whatsoever between the same function duplicated with different types.

Re: Generics aren't ready for Go

#119

Post by andy_ppp »

jstimpfle wrote: post #113
andy_ppp wrote: post #101

Earlier quoted context omitted.

"Hipster: A person who follows the latest trends and fashions, especially those regarded as being outside the cultural mainstream ." Yep. Go is a hipster language, even if you don't like it.

"The latest trends"? To me Go is particularly conservative. I don't feel like arguing over a word that has become essentially meaningless over time, but I think you have seriously misunderstood what hipster means or was once supposed to mean. Either that, or you don't really know about Go and are just judging it by its marketing's design aesthetics (Gopher, fonts etc. following a trendy googley style).

Go is trendy and Go is outside of the mainstream in it's minimalist design choices. Are you trying to say that Go is not in fashion and has made mainstream language choices?

I think you're just upset about the choice of the word hipster but as with all words it's a shortcut to actual meaning. It was intended with a hint of playfulness and not intended to make you feel bad, even if you don't agree with the choice of word.

Re: Generics aren't ready for Go

#120

Post by latronic_notron »

weberc2 wrote: post #58
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?

Yeah, you have to either give up type safety (Go's "void pointers" retain runtime type information, so it's closer to a Python object than a void pointer) or you have to write each implementation. In the case of linked list, that's not a big deal: `type List struct { Next *List; Value int}` and Go comes with a handful of useful generic types (slices, arrays, maps, channels, etc). It also has interfaces and closures,…

> "You can't ship software in a language without generics!"

Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code...

As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety.

interface{} does feel like a temporary and clunky solution for people used to generics.

> And lastly, one thing that you can't really appreciate without trying Go--the lack of generics/expressiveness and general simplicity of the language largely means everyone writes the same boring, predictable code, which means you can pretty much pick up any project on GitHub or your own code from years ago and understand it almost immediately.

I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested?

I personally find that using generics is way easier and faster than interface{}, Reflection or code generation. Also simpler and less error-prone than features from other languages like inheritance, operator overloading and unbounded coroutines.

Post reply on HN