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

51–60 of 238 posts

Re: Generics aren't ready for Go

#51

Post by kasey_junk »

emersion wrote: post #37
kasey_junk wrote: post #28

Earlier quoted context omitted.

Yet open up nearly any large golang codebase and you’ll find a channel being used to return a single answer response in the future.

What's wrong with that? Go has channels thus it doesn't need futures/promises.

Some problems are more simply modeled as futures/promises than csp.

Go’s unsophisticated type system makes it difficult to write a good standard generic data structure library such as a future/promise library.

That leads to people either writing a poor replacement, not using that style, or losing type safety. This is precisely what you would predict upon learning golang doesn’t have user defined genetics & ive had it bite me more than once in real projects.

Re: Generics aren't ready for Go

#52

Post by rebeccaskinner »

throwaway415415 wrote: post #42
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'…

Sucks for you, considered very good by plenty of other people who use it daily.

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.

Re: Generics aren't ready for Go

#53

Post by throwaway415415 »

bunderbunder wrote: post #43

I realize I'm not the audience here, but still -- As someone who isn't terribly familiar with Go, most of what I'm seeing in this article is the shady corners I can't see into. The generics one, I've seen plenty of pixels spilled on, and I've come to accept that I won't really grok the debate unless I spend some serious time programming in Go. What about the module system, though? Can anyone explain or share an artic…

Exactly. If you can't get rid of your favorite paradigm (which seems to be generics for some reason in this thread) then I guess stick with the language you are already using and don't try to wrap your head around other languages?

Re: Generics aren't ready for Go

#54

Post by kasey_junk »

rebeccaskinner wrote: post #52
throwaway415415 wrote: post #42

Earlier quoted context omitted.

Sucks for you, considered very good by plenty of other people who use it daily.

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.

Same

Re: Generics aren't ready for Go

#55

Post by emersion »

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.

Re: Generics aren't ready for Go

#56

Post by bunderbunder »

orbifold wrote: post #18

As a physicist I find out of context references to physics pretty annoying. No go modules are not like a grand unified theory, nor is any other go package management solution like general relativity.

Just enjoy that these kinds of references give you so much latitude for interpretation.

For example, in the absence of any practical exposition demonstrating that the module system solves problems that other systems don't, you can quite comfortably (and cynically, sure, but please let me have my fun) choose to interpret the analogy along these lines: General relativity is well-established, reasonably well-understood, and is essential to making a sizable chunk of the modern world (e.g., GPS) work. Whereas nobody's been able to demonstrate a working GUT yet, so currently its main practical use is as fodder for books and TV specials.

Re: Generics aren't ready for Go

#57

Post by throwaway415415 »

rebeccaskinner wrote: post #52
throwaway415415 wrote: post #42

Earlier quoted context omitted.

Sucks for you, considered very good by plenty of other people who use it daily.

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.

Re: Generics aren't ready for Go

#58

Post by weberc2 »

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, so you can generally go a long way without generics.

That said, there are still cases where generics would be useful; however, a lot of the people who complain about generics missing from Go tend to exaggerate the extent to which this is a problem, "You can't ship software in a language without generics!". In the case of Go, you have something like 97% type safe code compared to the many, many successful Python and JavaScript programs that ship with 0% type safety. 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. This isn't to say that generics aren't worth it; only that the debate kind of sucks because one side is ignoring that rather significant point.

Re: Generics aren't ready for Go

#59

Post by weberc2 »

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.

Callbacks are prolific in Go; not sure where you're getting this from...

Re: Generics aren't ready for Go

#60

Post by cdelsolar »

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.

"you don't even get proper error messages" - what are you talking about? Have you used Go?
Post reply on HN