slowly implementing all the things they said we didn't need
What did they say about proper enums.
Go: Support for Generic Methods
181–190 of 288 posts
Re: Go: Support for Generic Methods
#182Earlier quoted context omitted.
> As for the detractors, from the first generics proposal this was called out as a "not now", not never. What? The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods". There is also some similar discussion of the original generics proposal, with language like "then it's much less clear why we need methods at all". (I'm omitting some context, but I don't feel that it changes…
No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…
[deleted]
Re: Go: Support for Generic Methods
#183slowly implementing all the things they said we didn't need
Watching Go's development is like reliving the development of Java (which also didn't have generics at first), but over decades instead of years. Cannot wait for Go to implement an error handling system in the 2030s.
Thankfully we already have Java, so using Go is really for the scenarios where it cannot be avoided.
Re: Go: Support for Generic Methods
#184Earlier quoted context omitted.
Watching Go's development is like reliving the development of Java (which also didn't have generics at first), but over decades instead of years. Cannot wait for Go to implement an error handling system in the 2030s.
Its very funny watching certain segments of the programming industry rediscovering incredibly basic programming principles, after railing against them for so long. The AI people are starting to try and create formal specs to force the AI to generate an exact output, which is absolutely hilarious to me Dynamically typed/untyped languages finding that strict and visible typing is actually good is another
Another one, WebAssembly people recreating application servers, and networking object models.
Re: Go: Support for Generic Methods
#185Watch as this gets rejected for nonsensical reasons just like the issue about adding uint128, which also has been open for an extremely long time and they keep moving the goalposts as to reasons why it can't be done...
Re: Go: Support for Generic Methods
#186Earlier quoted context omitted.
That’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier. As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right
D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.
[dead]
Re: Go: Support for Generic Methods
#187Earlier quoted context omitted.
There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
Yes, all great examples of language design. PHP, Java, JavaScript, C, C++, Go
Re: Go: Support for Generic Methods
#188Re: Go: Support for Generic Methods
#189Earlier quoted context omitted.
It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.
...and Java didn't even have basic enums or sum types from the beginning. But it had null. They added enums, they added sealed classes. They're trying to get rid of null (apparently it's really hard). The problem is that in 2012, when go 1.0 was released, this should have been obvious to everyone. Here's a famous discussion from 2009, three years before the 1.0 release (tldr: facepalm) https://groups.google.com/g/gol…
The biggest design issue with adding value types and non nullable to Java, is that the number one design requirement of any solution is not to break Maven Central.
Every compiled JAR out there has to keep working as always on a JVM with updated semantics, and worse code has to be compatible, when passing class instances around between old and new code.
Then there are the guest languages on the JVM as well.
Re: Go: Support for Generic Methods
#190Earlier quoted context omitted.
If Go had just taken an off-the-shelf implementation of generics in 2009 then they could have spent the last 16 years deliberating over something useful, rather than attempting to reinvent programming language theory. The impression I have always gotten from Go's designers is that they are rather arrogant and averse to the idea of using other people's work. They want to develop everything from first principles, but b…
> and averse to the idea of using other people's work. They did use someone else's work, though. If you recall, Philip Wadler (of Haskell fame) designed Go's generics. > but by so doing end up with poor reinventions of well-studied concepts. Which is funny as there is probably nobody on earth that would be more capable than Wadler to get the job done. His pedigree in that area of work is pretty astounding. If he coul…
Yes, the same guy that supported the effort to add generics to Java, a decade beforee Go came to be, talk about not getting language design history.
Stop excusing them, they were the first to acknolowdge being wrong in first place,
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
-- https://go.googlesource.com/proposal/+/master/design/go2draf...