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

91–100 of 238 posts

Re: Generics aren't ready for Go

#91

Post by jstimpfle »

pjmlp wrote: post #75
jstimpfle wrote: post #45

Earlier quoted context omitted.

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.

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

Personally I care about true, hard dependencies much more than that "exposed for everyone else to see" fluff (the latter being only a subset of the former). Probably that is because I don't do business software, don't work in big teams etc.

What really matters to me is reducing hard technical dependencies, and recompile times and ABI compatibility may only be the two biggest reasons.

You're probably aware that I program predominantly in C, and "sitting in an ivory tower" is not a word that I would apply to typical C programmers. I wouldn't apply it to Java programmers, either. It's normally a term for the academic world, the world from which languages that focus on type theory originate.

Re: Generics aren't ready for Go

#92

Post by emersion »

norswap wrote: post #70
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.

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.

Then should all languages have all features?

As the author explains in the article, I don't think all languages should try to solve all problems perfectly.

Re: Generics aren't ready for Go

#93

Post by emersion »

bunderbunder wrote: post #81
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.

Bringing up C invokes my suspicions about this debate: It's really people with totally different use cases talking past each other. C doesn't have generics. Java has extremely limited generics. In both cases, it means that it's annoying and difficult for me to write a decent math library. I have to choose among making it support only one numeric type, implementing many copies by hand (one for each numeric type), or u…

I'd say either resort to code generation or pick another language that fits better your use-case.

Re: Generics aren't ready for Go

#94

Post by bunderbunder »

pjmlp wrote: post #83
bunderbunder wrote: post #81

Earlier quoted context omitted.

Bringing up C invokes my suspicions about this debate: It's really people with totally different use cases talking past each other. C doesn't have generics. Java has extremely limited generics. In both cases, it means that it's annoying and difficult for me to write a decent math library. I have to choose among making it support only one numeric type, implementing many copies by hand (one for each numeric type), or u…

C does have generics since C11, although relatively constrained.

To me, despite the name, _Generic(...) doesn't really count. It's more like a switch statement that lets you switch on a type instead of a value. You still have to manually write all your own implementations, which leaves you firmly in territory covered by the 2nd option I listed.

Maybe I'm missing something, though. On the rare occasion that I write C code, I stick to C99, so I haven't had much occasion to use it.

Re: Generics aren't ready for Go

#95

Post by bunderbunder »

emersion wrote: post #93
bunderbunder wrote: post #81

Earlier quoted context omitted.

Bringing up C invokes my suspicions about this debate: It's really people with totally different use cases talking past each other. C doesn't have generics. Java has extremely limited generics. In both cases, it means that it's annoying and difficult for me to write a decent math library. I have to choose among making it support only one numeric type, implementing many copies by hand (one for each numeric type), or u…

I'd say either resort to code generation or pick another language that fits better your use-case.

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

But that's a far cry from what TFA said. TFA read more to me as, "Go doesn't have generics because generic programming is a half-baked idea that isn't ready for prime time."

Re: Generics aren't ready for Go

#96

Post by rebeccaskinner »

throwaway415415 wrote: post #57
rebeccaskinner wrote: post #52

Earlier quoted context omitted.

I use Go daily and I agree with the general sentiment that it's a janky language full of warts and could really benefit from features like generics.

Maybe go back to java or c++? I'd rather have less people complain about a feature I don't want in the language.

I'd love to get away from Go again, but unfortunately it's the hot thing that people see on your resume and then they don't want to talk to you about anything else. I'm very concerned that in a few years it's going to be the terrible low-paying boring thing that people see on your resume and don't want to talk to you about anything else.

Re: Generics aren't ready for Go

#97

Post by atilaneves »

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

If I had the time, I'd love to apply the C to C++ diff on top of Go (templates, overloading, etc.), release it as Go++, and watch the world burn. Just for the lulz.

Re: Generics aren't ready for Go

#98

Post by atilaneves »

> they feel that generics are a good fit for this language

Or that it's ludicrous for any statically typed language to not have generics.

> It’s small and simple, and every detail is carefully thought out > Nearly all of Go’s features are bulletproof > my opinion are among the best implementations of their concepts in our entire industry

Uh huh.

> You could write a book called “C++: the good parts”, but consider that such a book about Go would just be a book about Go

Or it could be one-liner: "easy concurrency".

> simplicity and elegance are now the principles I optimize for

Doesn't everyone who cares? The problem is that elegance and simplicity, like beauty, are in the eye of the beholder.

To me, generics increase elegance and simplicity.

> If you’re fighting Go’s lack of generics trying to do something Your Way, you might want to step back and consider a solution to the problem which embraces the limitations of Go instead

So pretend it's the 70s and use void* (interface{})?

Re: Generics aren't ready for Go

#99

Post by bunderbunder »

bunderbunder wrote: post #95
emersion wrote: post #93

Earlier quoted context omitted.

I'd say either resort to code generation or pick another language that fits better your use-case.

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 not to have it, it's hard to see how it could be added without creating all sorts of language warts.

Re: Generics aren't ready for Go

#100

Post by pjmlp »

jstimpfle wrote: post #91
pjmlp wrote: post #75

Earlier quoted context omitted.

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.

> Exposed to the compiler doesn't imply exposed to everyone else to see. Personally I care about true, hard dependencies much more than that "exposed for everyone else to see" fluff (the latter being only a subset of the former). Probably that is because I don't do business software, don't work in big teams etc. What really matters to me is reducing hard technical dependencies, and recompile times and ABI compatibili…

I am applying that term to Go developers against generics no matter what.

C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware.

And yes I am aware that I kind of reversed the meaning of the term, but that is how it feels all the Luddite arguments against generics.

Just because there are plenty of old tech languages, which many in the generics crowd have a large experience using, doesn't mean we should keep using such approach at expense of productivity.

Post reply on HN