I'm a bit sad about the lack of acceptance for pluralism in widely used languages. The effort to get Go in line with other languages just seem so disproportional.
Notes on the Go2 Generics Draft
51–60 of 116 posts
Re: Notes on the Go2 Generics Draft
#52Earlier quoted context omitted.
Consider this function signature: func SomeAdditionFunction(arg1 int, arg2 int) { fmt.Println("Sum:", arg1 + arg2) } This function will only accept a pair of integers. In order to perform addition on floats or int64s or any other number type, you would need a separate function. Go has the concept of an empty interface (interface{}) which can accept any type. But this is not really a generic because you have to assert…
> In a language like Java, I could write this function to accept any type for which the + operator is valid, and it would still be type safe at compile time. I would not need to assert the types like I did above. Really? No. Not in Java. static void someAdditionFunction(T arg1, T arg2) { System.out.println("Sum:", arg1 + arg2); } "error: bad operand types for binary operator '+'"
That's because + is a java built-in unavailable to normal types. Usually something like an add method is used instead. It does not detract from the underlying point.
Re: Notes on the Go2 Generics Draft
#53Earlier quoted context omitted.
The Go team should have considered generics for Go 1.0 during the 0.x phase. It's 2018. We've done three decades of computer science since C, Oberon, or whatever the Go developers drew inspiration from. If you want your language to be taken seriously for large scale app development in the 2010s you need strong static typing, and a sophisticated, parametric type system. No exceptions. Advanced typing constructs like d…
> No exceptions Well, apparently Go _is_ an exception. It lacks what you point out and is, undeniably, a successful language.
How much would had it achieved if it didn't had the Google logo to go along it?
Lets say developed at SV startup XYZ instead.
Re: Notes on the Go2 Generics Draft
#54Every time I read a discussion about generics in Go, I remember discussions on the Small/SmartEiffel list where people argued that Eiffel doesn't need this or that because it can be emulated with a feature already available in the language. Well, Eiffel is history now.
Re: Notes on the Go2 Generics Draft
#55It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generi...
Exactly. Like all ideological arguments it completely ignores actual real-world evidence. Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling. My (anecdotal) experience and speculation suggests that you'd see massive reduction in complexity and lines of code ( especially when you consider code-gen). Bu…
Changing the language specifically requires experience reports. If that's not real world evidence i'm not sure what is.
The problem with the wider go community is they are usually not driven by evidence, but adherence to a philosophy. eg, its not possible to write large programs without generics.
Re: Notes on the Go2 Generics Draft
#56Earlier quoted context omitted.
> critics of Go aren't even Go developers This doesn't make the criticism invalid. I tried Go, found the lack of genetics / gopath / depends management too annoying, went back to other languages. I'm going to try it again after V2 is released. If only people continuing to use X could criticise X, we wouldn't get much progress.
I’m so conflicted about this comment because I have made nearly identical comments in the past. I think I’m going to have to change my stance on this point, however. There have been so many occasions that something about Go bothered me, and I then later discovered was a prerequisite to leveraging a much simpler programming model, that I am humbled by how much more I had to learn about programming. And I have to admit…
I wish more programmers were as thoughtful and humble as you. Sadly my personal experience is that most developers tend to be full of themselves and their opinions without even questioning them a bit.
Re: Notes on the Go2 Generics Draft
#57I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…
Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.
Re: Notes on the Go2 Generics Draft
#58I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…
> Programmers love generics because they enable higher-order abstractions, and programmers love abstractions
Right, because the alternative to higher-order abstractions is spending much of your time completing MadLibs-style implementation templates for solutions to solved problems instead of just including the library that contains the (higher-order) solution and focussing on solving the new part of the your problem.
Re: Notes on the Go2 Generics Draft
#59I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…
Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.
Ironically generics don't necessarily solve this. C# requires multiple implementations of numeric methods because int/float/etc don't sit in a type hierarchy.
It also doesn't really work in Java either because you have to use the Object types.
Even in rust this looks pretty complicated: https://travisf.net/rust-generic-numbers
Maybe it's easy in c++?
I've seem a similar comment made on almost every discussion of this issue... are folks just not aware of the limitations with generic implementations?
Re: Notes on the Go2 Generics Draft
#60I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…
Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.
That means Go is not the right tool for you. Don't use it.
It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.