Live data from Hacker News

Generics aren't ready for Go

drewdevault.com

191–200 of 238 posts

Re: Generics aren't ready for Go

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

golang authors seem to only have experience with C++ as they keep talking about C++'s deficiencies, as if it's the only other language that exists when it comes to generics.

Re: Generics aren't ready for Go

#192
post #129

Earlier quoted context omitted.

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

Plan9 didn't go anywhere. So other than UTF-8, there's not much to speak of. He's not a reference on programming language design, and it shows.

Compare to Leslie Lamport for instance, and the tremendous effect he had on large scale systems and software engineering correctness.

Re: Generics aren't ready for Go

#193
post #131

Earlier quoted context omitted.

D, Rust, C#, ML, Delphi, etc.

I haven't used all the other ones, but "Delphi" really made me crack up. I used it for 6 months before I quit my job. It's a mess, junk after junk added on a pile of junk, only surpassing the junk-adding badness of C++ by also having this broken standard library that's somehow required to write any type of software (because the simplest thing, C-like pointers, exist but are really not nice to work with). The task tha…

I was referring to generics systems that don't suck.

Re: Generics aren't ready for Go

#194
post #191

Earlier quoted context omitted.

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.

golang authors seem to only have experience with C++ as they keep talking about C++'s deficiencies, as if it's the only other language that exists when it comes to generics.

Sure. Seems like they have the same experience than me then.

Re: Generics aren't ready for Go

#195

Earlier quoted context omitted.

Because they are easily abused (look at c++) and makes code unreadable. Working around generics usually make the code clearer and thus more secure

Go has interface{}, which can be abused as much as generics for the same purpose, but without the type safety, hence, less secure. And nobody is advocating C++ style template metaprogramming. There are much better implementations of generics, as acknowledged by Russ Cox himself.

Usually interface{} is abused by java programmers. I agree that it's not great, but if you don't come from java or c++ chances you won't follow these patterns at least.

Re: Generics aren't ready for Go

#196
post #141
post #127

Earlier quoted context omitted.

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

Re: Generics aren't ready for Go

#197
post #70

Earlier quoted context omitted.

If you nitpick enough, nothing is essential. We can write everything in C, or heck, even assembly. "If you're not happy go look elsewhere" doesn't move the needle on the question "Should Go have generic" at all. It's not an argument at all.

Then should all languages have all features? As the author explains in the article, I don't think all languages should try to solve all problems perfectly.

I don't see how that is the point I made. The point I made was that an argument should be given as to whether a feature should be in the language or not.

Note that this leaves the possibility that a feature should not be in the language, even if it does solve a real problem.

Both arguments do not address whether the language should have a feature or not.

"Not essential" might be recast as a valid argument, but must be rephrased in terms of cost vs benefits of the feature examined wrt the goals of the language.

Re: Generics aren't ready for Go

#198
post #192

Earlier quoted context omitted.

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.

Plan9 didn't go anywhere. So other than UTF-8, there's not much to speak of. He's not a reference on programming language design, and it shows. Compare to Leslie Lamport for instance, and the tremendous effect he had on large scale systems and software engineering correctness.

Can you argue your case as well as he does? https://www.youtube.com/watch?v=cQ7STILAS0M

Or are you just being disrespectful?

Re: Generics aren't ready for Go

#199

Earlier quoted context omitted.

> It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism. And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) Even if I were making a positive assertion like "generics costs more than it ga…

> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically! > Because "generics" as a feature suffices to support multi-paradigm programming. I don't really agree with that. Despite being widely used in functional languages, they aren't really a…

On a phone, so sorry in advance for terse response. Agreed that the language would be simpler in some sense with generics; I don’t think it would be more readable due to aforementioned increase in expressivity. Interesting point about first class functions, and while I largely agree, the variation in Go code is still small and constrained which is my point. :)

Re: Generics aren't ready for Go

#200

Earlier quoted context omitted.

> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically! > Because "generics" as a feature suffices to support multi-paradigm programming. I don't really agree with that. Despite being widely used in functional languages, they aren't really a…

On a phone, so sorry in advance for terse response. Agreed that the language would be simpler in some sense with generics; I don’t think it would be more readable due to aforementioned increase in expressivity. Interesting point about first class functions, and while I largely agree, the variation in Go code is still small and constrained which is my point. :)

You don't find the existing Go code using the built-in generics (arrays, dictionaries, channels) readable? You find that its expressiveness makes it too complex?
Post reply on HN