Live data from Hacker News

Generics aren't ready for Go

drewdevault.com

121–130 of 238 posts

Re: Generics aren't ready for Go

#121

Earlier quoted context omitted.

"The latest trends"? To me Go is particularly conservative. I don't feel like arguing over a word that has become essentially meaningless over time, but I think you have seriously misunderstood what hipster means or was once supposed to mean. Either that, or you don't really know about Go and are just judging it by its marketing's design aesthetics (Gopher, fonts etc. following a trendy googley style).

Go is trendy and Go is outside of the mainstream in it's minimalist design choices. Are you trying to say that Go is not in fashion and has made mainstream language choices? I think you're just upset about the choice of the word hipster but as with all words it's a shortcut to actual meaning. It was intended with a hint of playfulness and not intended to make you feel bad, even if you don't agree with the choice of w…

> Are you trying to say that Go is not in fashion and has made mainstream language choices?

I can't even understand how you can be constructing such a statement. "In fashion" and "mainstream" are pretty synonymous to me. In consequence, the statement is contradictory. Hence, No, I am clearly not trying to say that.

> I think you're just upset about the choice of the word hipster

No I'm saying that the team behind Go is just really considerate and principled. They don't follow all the latest fads, simply because those fads are the reason why so many other languages suck and projects written in them become giant unmaintainable hairballs.

They are engineers (label them conservative if you like). Not hipsters.

Re: Generics aren't ready for Go

#122
post #84

Earlier quoted context omitted.

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

With thousands of institutional users? Implementing distributed databases?

As much as old time mainframes and Novell NetWare based applications could have.

Re: Generics aren't ready for Go

#123

>Have you ever seen someone write something to the effect of “I would use Go, but I need generics”? Perhaps we can infer from this that many of the people who are pining after generics in Go are not, in fact, Go users. This is the sort non-adhominem adhominem attack that makes these debates so tedious. Obviously, someone deciding not to use Go for lack of generics after giving it a serious try would end up not being…

In addition there are plenty of people who do use Go yet still criticise its lack of generics. But apparently these are not “real” Go users?

Re: Generics aren't ready for Go

#124
post #100

Earlier quoted context omitted.

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

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

It looks more of "we are working on it excuse" to keep people at bay.

Rob Pike has done a presentation last year where he stated that he doesn't have anything to do with it and is very sceptical of it being ever added.

So WIP is kind of euphemism.

> Not sure what was your intention behind that statement.

That even languages born before generics are willing to move forward.

Google is majorly a Java, Python, C++ shop. Go is usually more outside than internal Google projects.

If we reduce Go lack of features to stuff that C doesn't provide, maybe bounds checking, modules and GC aren't required as well.

As for complaining, projects like Docker and K8s ensure that those of us that rather not use Go, have to deal with it in some form anyway.

Re: Generics aren't ready for Go

#125

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

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?

Re: Generics aren't ready for Go

#126

Earlier quoted context omitted.

That is a meaningless statement. You can do anything in (almost)any language that doesn't mean the basics are solved.

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

Re: Generics aren't ready for Go

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

Re: Generics aren't ready for Go

#128

Earlier quoted context omitted.

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

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 languages (which golang isn't) like Kotlin or even C# for instance.

It's very evident that the golang authors have no experience designing language, and didn't look in depth at what other languages did.

Re: Generics aren't ready for Go

#129

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

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 banks and HFT firms.

Re: Generics aren't ready for Go

#130
post #25

Earlier quoted context omitted.

First go does have generics. It just doesn’t have user defined generics. But to answer your question go has really mediocre support for a wide variety of problems. Some that burn me a lot is support for future/promises and support for modern lock free algorithms. So you end up either writing non-optimal replacements, losing type safety or in some case code generation is used.

use channel + goroutinue for that. Goroutinue are very light weight. Zero size channel works like promise

Which makes code even more messy than just using Futures.
Post reply on HN