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

81–90 of 238 posts

Re: Generics aren't ready for Go

#81

Post by bunderbunder »

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.

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 using some sort of ugly code generation tool - who knows what in Java, the preprocessor in C - to implement all those copies.

Which might not be a problem for everyone, but, for my use case, it's annoying.

(Deliberately avoiding the "generic library of data structures" use case because, while generics are what brought that to most of us (edit - in the world of static typing), it would appear that Go's handling that case just fine without them.)

Re: Generics aren't ready for Go

#82

Post by pjmlp »

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.

Of course it isn't an essencial feature, all the older timers here had to code with programming languages without generics support for a couple of decades.

By the way, C has minimal generics support since C11.

Re: Generics aren't ready for Go

#83

Post by pjmlp »

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…

C does have generics since C11, although relatively constrained.

Re: Generics aren't ready for Go

#84

Post by pjmlp »

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?

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

Re: Generics aren't ready for Go

#85

Post by Foober223 »

An algorithm or data structure may be applied to various types of data. There's various ways to handle this. Macro expansion, generics (basically equivalent of macro expansion but as a language syntax), or losing types: void pointers, duck typing, interfaces.

Go puts it's head in the sand and and handles the problem like it's 1970 with the "void pointer" way of thinking. That's fine if you're using a dynamic language (ie python, lisp) and firmly decided your trade offs with regards to types and performance. But if you elect to use a statically typed language, it would be nice to reap the benefits.

Modern C++ is still the only way to go for serious software. Rust maybe in the future as the compilers improve. Go is a no no-go.

Re: Generics aren't ready for Go

#86

Post by jstimpfle »

ben-schaaf wrote: post #65
jstimpfle wrote: post #26

Earlier quoted context omitted.

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

Thanks for the correction, I shouldn't say "generics". But rather "Go programmers don't have user-defined generics, they use interface{}" or something along those lines.

Other than that, I don't think we're in disagreement here.

Re: Generics aren't ready for Go

#87

Post by mirekrusin »

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.

They did pop up in short period of time and go projects are generally considered quite stable - how can you achieve those without "basics being solved"? IMHO basics is precisely what they did solve exceptionally well.

Re: Generics aren't ready for Go

#88

Post by robmccoll »

heavenlyblue wrote: post #36
emersion wrote: post #24

Earlier quoted context omitted.

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.

That's so true. It would be great to be able to have very limited / very short macros as a compromise.

    var a = n1;
    if a
vs.

    var a = max(n1, n2)
without having to write and make a function call.

I still want something more powerful for error handling like a type that if it is ever assigned non-nil the method returns immediately.

   var err autoreturn error

   rslt, err = pkg.MaybeError()

Re: Generics aren't ready for Go

#89

Post by johnydepp »

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.

Go channels are very handy and magnitude of less spaghetti than futures. And goroutines have good performance.

I think people are used to futures etc, that's why the new concept feels strange.

I think the goroutines and channels are the biggest features which compensates for generics.

Re: Generics aren't ready for Go

#90

Post by Insanity »

alexandercrohde wrote: post #80
Insanity wrote: post #63

Earlier quoted context omitted.

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.

It's not 'objectively better' to be honest. Offering two ways of doing the same thing can lead to a non-uniform codebase, and can lead to people being 'experts' in functional and others being experts in procedural. And at some point, the procedural guys will get a mindfuck reading the functional people their code.

(We had something similar happen).

Post reply on HN