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

201–210 of 238 posts

Re: Generics aren't ready for Go

#201

Post by rebeccaskinner »

throwaway415415 wrote: post #162
rebeccaskinner wrote: post #96

Earlier quoted context omitted.

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.

Its the hot thing for a reason. Adapt or be left out.

I've been using Go in production for 5 years now, I don't think there's a lot of adapting left to do. From the other side of a few years of experience I think I see the reality of the situation pretty clearly. Go isn't a good language by any means. It's the hot thing because it's a marginally less painful blub than python or java and cheap entry-level developers can be onboarded to it quickly and be left to churn out boring but largely unharmful code. On top of it's programming with mittens mentality it had the force multiplier effect of becoming the devops language dejure. I think the staying power of Go is largely dependent on whether or not the industry finds the current state of devops a local maxima that it sticks on for a while, or whether things push further into PaaS territory and the current devops tooling becomes irrelevant for everyone except the big cloud platform implementers.

Re: Generics aren't ready for Go

#202

Post by yawaramin »

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.

> I’ve come across much much better solutions to my problems than I would have if Go offered a crutch to my flawed thinking.

Any example where you have a better solution than using generics?

Re: Generics aren't ready for Go

#203

Post by zeveb »

latronic_notron wrote: post #120
weberc2 wrote: post #58

Earlier quoted context omitted.

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…

People always go on about type safety, but in practice it normally doesn't matter. I have an instance of a data structure; I put in items of type Foo; I remove items of type interface{} and immediately cast them to type Foo, and life goes on. Sometimes, I might need to put in items of different types, and then I use a type switch. It's not a big deal, nothing panics, I get on with my life.

Yes, there's a class of programs for which this is not the case, and for which I might want some sort of fancier guarantees. But those don't tend to be the sort of programs I write. My hobby projects are in Common Lisp; I used to professionally program in Python and JavaScript (for my sins) — Go is strictly better than those in the static-typing department.

Would I like generics? Sure, I can see how they'd be nice. But I remember how templates in C++ turned into something nasty, and I've written Java professionally too: I like how clean & simple Go is. I can write code, then be done with it, and come back a year or two later and not be mystified. It's a decent little language for getting stuff done.

Re: Generics aren't ready for Go

#204

Post by zeveb »

nicoburns wrote: post #3
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?

My understanding is that the standard library containers implement generics via special compuler magic, and everyone else is using `interface {}`, which is the equivalent of a void point or "any" type in Go.

It's really not the equivalent of a void pointer, because interface{} is still typed, and you can still interrogate its type, and the runtime prevents you from using it as any type other what it actually is. So it's far safer than a void pointer, although it can crash the program — but cleanly (because of the aforementioned runtime checks).

Re: Generics aren't ready for Go

#205

Post by spion »

apta wrote: post #190
spion wrote: post #141

Earlier quoted context omitted.

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal interfaces kinda suck. Java also lacks green threads. There is baggage in the design of many libraries related to previous lack of lambdas that is now annoying. The Go documentation as well as standard interfaces are tastefully and minimally done (for an impera…

> Java also lacks green threads Green threads are not the be-all-end-all solution for concurrency. They have their place, but so do event based async io. That being said, Java is getting green threads in the form of Fibers. > Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm... . Obviously Java's Reader interface does more work, and has a `close()` met…

Can Quasar fibers be efficiently used with other (popular) Java libraries that build on top of the standard libraries? If not, I don't consider that to be good developer experience. That is more of a mistake that cannot be rectified.

Async IO is also fine. The question is, what is your current ecosystem built on top of. AFAIK the answer with Java is definitely not async IO or fibers.

Yes, structural interfaces in Go are implemented poorly. But the standard library uses them very tastefully, putting most standard libraries to shame :) Go also has Closer, and its a separate interface - interfaces are minimal which makes them much easier to implement and more generally applicable.

Re: Generics aren't ready for Go

#206

Post by spion »

tedunangst wrote: post #196
spion wrote: post #141

Earlier quoted context omitted.

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal interfaces kinda suck. Java also lacks green threads. There is baggage in the design of many libraries related to previous lack of lambdas that is now annoying. The Go documentation as well as standard interfaces are tastefully and minimally done (for an impera…

> Java also lacks green threads. So weird. Java used to only have green threads. The very name, "green threads", comes from the fact that's what the JVM called them. Literally invented the name.

Too bad they were removed. I don't see why a non-system language should use anything other than green threads nowadays.

Re: Generics aren't ready for Go

#207

Post by je42 »

throwaway415415 wrote: post #165
apta wrote: post #128

Earlier quoted context omitted.

Keep in mind that many golang programmers just parrot what the golang authors say, without fully understanding it or even realizing the golang authors are wrong (not saying that's the case in this specific instance). They hear the golang authors complain about Java, that it's the only way to do things, so they think that the only other solution is to go the extreme opposite way, not even looking at real modern langua…

Unfortunately I am not parroting. If you are used to read code, and you read c++, you will see that templates are abused. No generics force devs to make their code clearer and thus more secure. It is evident that Go is a better language than most thanks to the creators having deep experience in that domain.

for sure i can abuse Go's language features as well in unintended ways.

Language abuse happens when the feature is the only available feature to implemented a particular and no other language feature allows for a better implementation.

in C++ most abuses of template are related to the missing feature "concepts". which took quite a while to get their.

If language switching is not an option, and your application requires generics and you are also required to use Go, you do have a problem. You need abuse the language and work around re-implement generics for Go.

Which can result in a very ugly development process, difficult to maintain code etc.

Re: Generics aren't ready for Go

#208

Post by je42 »

zeveb wrote: post #203
latronic_notron wrote: post #120

Earlier quoted context omitted.

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

People always go on about type safety, but in practice it normally doesn't matter. I have an instance of a data structure; I put in items of type Foo; I remove items of type interface{} and immediately cast them to type Foo, and life goes on. Sometimes, I might need to put in items of different types, and then I use a type switch. It's not a big deal, nothing panics, I get on with my life. Yes, there's a class of pro…

You should read the typescript threads, where people want types to make their code more bug free.

Re: Generics aren't ready for Go

#210

Post by grumpydba »

pjmlp wrote: post #189
grumpydba wrote: post #137

Earlier quoted context omitted.

> So does C, C++, Java, etc. That statement is meaningless. It just means that with enough contortion, you can write some code in golang that works. Indeed it's as capable as those languages in this domain. The productivity is higher though, thanks to the stdlib.

Go's stdlib is a tiny portion of what Java and .NET offer.

Yes those are two bloated stdlibs.
Post reply on HN