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

141–150 of 238 posts

Re: Generics aren't ready for Go

#141

Post by spion »

apta wrote: post #127
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'…

> Go biggest advantage isn't the language, its the decent documentation and standard library design Which, ironically, Java is just superior in every way when it comes to documentation of the standard library. Large open source Java projects are well designed and very well documented, unlike golang projects.

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 imperative language): https://golang.org/doc/ - e.g. https://golang.org/pkg/io/ ... To my knowledge there is no equivalent of this for Java that comes close.

Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm...

Java has pretty nice generics. With Java 10 the language is now decent too.

Re: Generics aren't ready for Go

#142

Post by spion »

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.

There are plenty of people who consider C++ good too and its used by people daily. Doesn't mean that Rust isn't a better language, even though there are less people that use it daily.

I think we need to be real about what are the strengths and weaknesses of each platform instead of drinking the coolaid. Otherwise we don't learn anything and the bad parts are going to find their way in the next one.

Re: Generics aren't ready for Go

#143

Post by grumpydba »

Foober223 wrote: post #85

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…

> Modern C++ is still the only way to go for serious software.

Please define serious software.

Re: Generics aren't ready for Go

#144

Post by overcyn »

bunderbunder wrote: post #134
jstimpfle wrote: post #125

Earlier quoted context omitted.

Or maybe the academics and type theorists are philistines about the software that runs the world and their arguments have mostly been about hand-picked toy examples? Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time?

So, we would seem to have two key statements being pitted against each other here: 1. Rob Pike doesn't have a strong grasp of type theory. 2. Rob Pike is an accomplished programmer. To me, this conflict of opinions is structurally indistinguishable from 1. That shape over there is a square. 2. That shape over there is blue. IOW, there is no argument to see here.

No the two conflicting statements are.

1. Go doesn't have generics because the authors didn't have strong grasp of type theory.

2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.

Re: Generics aren't ready for Go

#145

Post by weberc2 »

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…

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

It's not a strawman; I run into this tired argument too often, so I wanted to call it out to avoid the predictable digression. There is a strong case for generics and I empathize with "`interface{}` is clunky..."; I just want a debate that recognizes the tradeoffs.

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

I don't think I made the argument that "generics are more complicated than other features". My argument was that Go code is boring and predictable (consistent). It stands to reason that boring, consistent code is easier to read and understand than novel and/or mixed-paradigm code. Generics increase expressiveness, which pretty much by definition means fewer rails to keep code consistent. I'm not arguing that Go's current feature set strikes an optimal balance between expressiveness and consistency for all problems; however, it does do a pretty good job and we should count the costs as well as the gains when considering a new feature.

Re: Generics aren't ready for Go

#146

Post by jstimpfle »

apta wrote: post #129
jstimpfle wrote: post #125

Earlier quoted context omitted.

Or maybe the academics and type theorists are philistines about the software that runs the world and their arguments have mostly been about hand-picked toy examples? Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time?

> Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time? What are the credentials to back this up? Otherwise, the languages he makes fun of actually are used to deliver large scale systems in real time. Google is built on C++ and Java, so are most of the other top tech companies, not to mention bank…

He is one of the Unix figures at Bell Labs (although a late-joiner, being younger), he designed UTF-8 with Ken Thompson, and worked on the Plan 9 project, before joining Google. That's probably more than most of us will ever achieve.

Re: Generics aren't ready for Go

#147

Post by aikah »

dana321 wrote: post #118
aikah wrote: post #111

Earlier quoted context omitted.

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

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

Don't be obtuse, nobody ever said "Generics are a cure-all".

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

Yes there is, it's called polymorphism.

Re: Generics aren't ready for Go

#148

Post by jstimpfle »

overcyn wrote: post #144
bunderbunder wrote: post #134

Earlier quoted context omitted.

So, we would seem to have two key statements being pitted against each other here: 1. Rob Pike doesn't have a strong grasp of type theory. 2. Rob Pike is an accomplished programmer. To me, this conflict of opinions is structurally indistinguishable from 1. That shape over there is a square. 2. That shape over there is blue. IOW, there is no argument to see here.

No the two conflicting statements are. 1. Go doesn't have generics because the authors didn't have strong grasp of type theory. 2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.

Well that was what I was trying to say anyway. Thanks for clarifying!

Re: Generics aren't ready for Go

#149

Post by weberc2 »

apta wrote: post #126
weberc2 wrote: post #116

Earlier quoted context omitted.

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.

> The parent should have said, "Go is regularly used to ship..." 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. But that doesn't mean mean there aren't better, safer ways to write code. As others said, you can write large systems in C, but we still see the fallouts of using a very limited and unsafe language. And the f…

> So does C, C++, Java, etc. That statement is meaningless.

You're not following the conversation. The question is "Does Go solve 'the basics'?", not "Is Go better than C, C++, Java, etc?". I noted that Go solves 'the basics' for any meaningful definition of the term, as evidenced by regularly shipping useful software; I didn't claim that "regularly shipping useful software" makes it better than other languages.

> And the funny things is, how do some of these larger projects get around golang's limititions? They write code generators to emulate mocking and generics, ending up with a weird mix of code that is difficult to manage. I saw this at my current employer, where they use golang for most of their backend. It's funny that I always think that even writing in Java would make the code base a lot more maintainable and even shorter and less verbose.

This is a fallacy. A code generator is a pain in the ass to work around generics, but it's entirely possible and likely that the efficiencies gained by Go (versus Java or other candidate languages) more than justify the losses due to a code generator compared.

It's also entirely possible and likely that people are throwing code generators at problems (like mocking) that don't require or benefit from code generators.

Re: Generics aren't ready for Go

#150

Post by jstimpfle »

latronic_notron wrote: post #136
jstimpfle wrote: post #132

Earlier quoted context omitted.

> 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 a C programmer (which doesn't have generics either) I can't recall the last time where that additional safety was being missed. Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvi…

> Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Except when it isn't. Except when it crashes in production. I believe this is the kind of situation people are trying to avoid with type safety... > Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree for types K and V"?…

> Except when it isn't.

Yes, but by far more important are bounds checks. Go has bounds checks. As a C programmer I don't get to enjoy them (I get to write simpler, non-GCed, object-cruft-free software in exchange). Out of bounds reads and writes consume far far more of my time compared to void pointers. (And even OOB are not that time consuming).

> That's uncalled for, isn't it? There's a lot of non-toy problems...

Yes, the Fibonacci was a bad example (couldn't use Map because Go has that). It wasn't meant in a mean way.

Post reply on HN