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

101–110 of 238 posts

Re: Generics aren't ready for Go

#101

Post by andy_ppp »

jstimpfle wrote: post #38
andy_ppp wrote: post #19

Earlier quoted context omitted.

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.

Is "hipster" a label you would like to apply to e.g. Russ Cox? Maybe the designers of Go have design goals that are different than what you have in mind. Maybe they don't see it as "simplicity vs utility", but more as "utility through simplicity".

"Hipster: A person who follows the latest trends and fashions, especially those regarded as being outside the cultural mainstream."

Yep. Go is a hipster language, even if you don't like it.

Re: Generics aren't ready for Go

#102

Post by jstimpfle »

pjmlp wrote: post #100
jstimpfle wrote: post #91

Earlier quoted context omitted.

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

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

They are actively looking for something that doesn't suck. Aren't they?

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

Not sure what was your intention behind that statement. But of course I'm aware of C11 Generics. And they might be nice for a generic min() and max() and similar but other than that honestly I have little use because types are not values and in C, types are not elevated to be much more than simply physical layout. Whenever I've tried to encode meaning in types in any language I've failed spectacularly. Feel free to make Oddintegers and Evenintegers all day long if that's what makes you happy.

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

Let's get a life and not spend all of our time raging against people doing different things differently. At Google, I'm sure Go does solve real headaches they have with C++ ((re)compilation issues being only the worst offenders) and Python (performance...). And probably it does so better than any other language can. Because, Google is still primarily an engineering company, not a hipster company, nor a language-obsession company.

Re: Generics aren't ready for Go

#103

Post by cannabis_sam »

It’s weird seeing all this post-hoc rationalising when there is a perfect explanation for why go doesn’t have generics:

Rob Pike didn’t bother to look into any of the research into type theory and programming language technology. Hence his understanding of types were restricted to Java and C++ and similar (whose type systems are an abomination), and he could not separate subclass polymorhism with inhertance from parametric polymorhism.

    But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.
    That's the detail that sticks with me.

    Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.

    My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just that.
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

I mean he’s openly contemptous of the academics who do research in his field, while wildly mistepresenting their work. But people eat that shit up, because ”OMG it’s Rob Pike” instead of actually discussing the underlying issues.

Yes Rob, you are a philistine when it comes to types.. (or at least were)

Re: Generics aren't ready for Go

#104

Post by dana321 »

aikah wrote: post #69
dana321 wrote: post #17

Earlier quoted context omitted.

using interface{} and reflect is good enough for the many problems of using X datatype

No it is not. What's the point of a compiler if you check types at runtime? It's just that a lot of things in Go weren't carefully designed and now the price of adding something to the language is the price of dealing with technical debt. For instance Go has a form of exception (panics), returning errors is purely a convention. But panics aren't very good at exceptions either.

Well, what was the point of adding std::any in C++17?

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.

Re: Generics aren't ready for Go

#105

Post by rebeccaskinner »

weberc2 wrote: post #78
rebeccaskinner wrote: post #67

Earlier quoted context omitted.

Interfaces help a little bit. You can't really build re-usable data structures without falling back to `interface{}` and then incurring a performance hit from using reflection to get a well-typed value back out; but you can at least make your bespoke structures very marginally more reusable by defining interfaces ad-hoc.

To be clear, you use cheap type assertions to get a well-typed value back out. You can use expensive operations from the `reflect` library to do other things, but not to get a well-typed value back out.

Looking at some benchmarks it does look like newer versions of Go at least have pretty reasonable performance for type assertions. That makes the situation a little less bad, but doesn't negate the general ugliness of having type assertions every time you want to get a value back out of a generic data structure.

Re: Generics aren't ready for Go

#106

Post by weberc2 »

rebeccaskinner wrote: post #105
weberc2 wrote: post #78

Earlier quoted context omitted.

To be clear, you use cheap type assertions to get a well-typed value back out. You can use expensive operations from the `reflect` library to do other things, but not to get a well-typed value back out.

Looking at some benchmarks it does look like newer versions of Go at least have pretty reasonable performance for type assertions. That makes the situation a little less bad, but doesn't negate the general ugliness of having type assertions every time you want to get a value back out of a generic data structure.

Fully agree; dealing with `interface{}` is generally pretty tedious.

Re: Generics aren't ready for Go

#107

Post by andy_ppp »

cdelsolar wrote: post #60
andy_ppp wrote: post #19

Earlier quoted context omitted.

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?

Yes. Have you used programming languages with good error messages?

Re: Generics aren't ready for Go

#108

Post by dana321 »

mixedCase wrote: post #44
dana321 wrote: post #17

Earlier quoted context omitted.

using interface{} and reflect is good enough for the many problems of using X datatype

One of Go's tennets is "clear is better than clever", followed by "reflection is never clear". So no, idiomatic Go is not about using reflection, it's what we have to resort to because the language is so limited.

We're talking about simple reflection here, pass in the value, infer the type and cast to that type.

Most people are totally confused by generics, i personally don't have a problem using them or not. At the end of the day, its just template metaprogramming.

Re: Generics aren't ready for Go

#109

Post by smolder »

The way he describes Go's existing feature set as unwavering perfection is disappointing. No language is perfect except in heavily constrained context. They all make trade offs. GC is itself a compromise and so it follows that Go is not the one true language.

Re: Generics aren't ready for Go

#110

Post by latronic_notron »

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.

Just curious: why don't you want generics in Go?

The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}.

It's not as if Go is a language without warts... there's a lot of ugly stuff, like Iota, Reflection, the error handling, interface{} itself.

This is a legitimate question, btw. Legitimately looking for other points of view

Post reply on HN