61–70 of 116 posts
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.
Sad indeed.
Earlier quoted context omitted.
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…
But most other data structures? Nope. Too much of the algorithm depends on the primitive type.
And that makes generics a nice boon for computer scientists and certain library authors, but of middling benefit for day-to-day coding. If the container works, you can copy-paste-modify your way to the types you want, or automate the same in a macro or code generator. It's not beautiful but it doesn't have to be.
Earlier quoted context omitted.
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…
I'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…
Earlier quoted context omitted.
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…
In agreement. IMHO generics basically have one place where they work well: abstract containers. Your queues, linked lists, what-have-you can benefit. But most other data structures? Nope. Too much of the algorithm depends on the primitive type. And that makes generics a nice boon for computer scientists and certain library authors, but of middling benefit for day-to-day coding. If the container works, you can copy-pa…
It'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...
It’s weird to see complaints about code generation causing a too big code base at compile time when code generation is exactly what a compiler will do behind the scenes for generics.
Earlier quoted context omitted.
I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…
> hate using that term but it really was largely just individuals who decided that didn't like Go from the outset anyway so weren't exactly day to day Go developers I'm a day-to-day Go developer and maintain some of the most widely used Go projects out there. While I understand their wish to do things "slow and steady" there were several other missteps and double-downs by the language designers that left me with a bi…
However I don't think that's so much an issue with the lack of generics nor Java-esk exceptions but rather it's memory management and green threads. You may disagree with me though - the stuff you work on is definitely a level or two up from anything I've attempted in Go.
I'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…
Developers love to be able to write their magical code and their clever abstractions and often forget that their code is paying the price by becoming less clear and less readable. From a security perspective that's a huge loss.
I know that people with the right security mindset will do the right thing, and have more code where it improves clarity, or have slower code when it makes it easier to understand what is being done. But unfortunately that's a tiny minority of developers.
Earlier quoted context omitted.
I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…
> Sometimes it feels like those who are the loudest critics of Go aren't even Go developers Perhaps unsurprisingly, those who didn't like what they saw when taking a look at Go might well have chosen to work in other languages. This might be a basis on which to prioritize criticism -- certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't us…
Maybe if the language was unsuccessful then yes. But given the popularity in f Go it's fair to say the concerns of its existing user base should take precedence over those that may not use the language regardless.
> certainly the criticisms of those who use a language are more important to those managing it than the complaints of those who don't use it -- but it's not a reasonable basis on which to disqualify criticism.
But as this topic has demonstrated, those concerns haven't been disqualified out if hand either.
> And to point a criticism back: sometimes it feels like some of Go's loudest defenders don't choose to offer the discussion much beyond that response ("you're not really using it because if you were you'd see that the pain point you're describing is imaginary or not that bad or has plans to make plans to be fixed").
I disagree that happens. In my first post I made the arguement about language stability (not breaking things). Others have made the arguement of simplicity and/or readability as well. I think the real issue is some people don't consider those good enough reasons so dismiss the counterarguments out if hand. Which is obviously an opinion you're entitled to but you have to remember that it's the stability and simplicity that has made Go popular in the first place so those points actually do matter to a great many of us.
The thing is, there is already C#, Java, Rust, C++, and a great many other languages out there that have rich ecosystems and expressive semantics, Go has gone in a different direction by being a boring language. This direction clearly divides people though.
It'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…
And also how most codebases would be worsen.