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.
Generics aren't ready for Go
191–200 of 238 posts
Re: Generics aren't ready for Go
#192Earlier 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.
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
#193Earlier 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…
Re: Generics aren't ready for Go
#194Earlier 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.
Re: Generics aren't ready for Go
#195Earlier 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.
Re: Generics aren't ready for Go
#196Earlier 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…
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
#197Earlier 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.
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
#198Earlier 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.
Or are you just being disrespectful?
Re: Generics aren't ready for Go
#199Earlier 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…
Re: Generics aren't ready for Go
#200Earlier 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. :)