Earlier quoted context omitted.
"Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics?" It's both. Adding only concise flow control, such as with the ? operator, works poorly if all you can return is multiple non-generic values; various common permutations get awkward in that case. And as you point out Result doesn't achieve much without the concise operators. Rust has very successfully shown the benefi…
I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.
Expectations for generics in Go 1.18
61–70 of 209 posts
Re: Expectations for generics in Go 1.18
#62> Because we will not know what the best practices are for using generics, Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go. But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.
Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)
(And of coures we've been able to write generic code in dynamic languages for a long time as this is a static typing concept)
Re: Expectations for generics in Go 1.18
#63Earlier quoted context omitted.
On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?
Canadians now roll with the term Indigenous instead of Aboriginal
Re: Expectations for generics in Go 1.18
#64Earlier quoted context omitted.
GC Shape Stenciling, a hybrid of stenciling and dictionaries: https://go.googlesource.com/proposal/+/refs/heads/master/des...
So there's a runtime cost for using generics?
Re: Expectations for generics in Go 1.18
#65> Because we will not know what the best practices are for using generics, Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go. But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.
Re: Expectations for generics in Go 1.18
#66Earlier quoted context omitted.
I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.
I like what Chris Lattner said about language design in Lex Fridman podcast, that you know when you're doing something right because it "feels" right. Rust has a bunch of syntactic sugar which gets critised in many languages, but to me things like error returns with ? "feels" right. Love Go as well, and the error handling makes a lot of sense in concept but it just doesn't "feel" nice to look at or use. I like there'…
Re: Expectations for generics in Go 1.18
#67From the outside, it seems like adding generics to Go seems similarly controversial and slow as the Python jump to version 3 — although Go generics haven’t even landed yet. Generics have the potential to impact a decent amount of the standard library. Although I’m not surprised that they are not doing a major version bump given the isolation of the feature at this stage, it will be interesting to observe its uptake i…
I don't think it's anything like the Python jump from 2 to 3. That changed the behavior of a lot of code (unicode vs bytes, various syntax changes, import changes, etc), and there was no way to automatically upgrade a codebase (2to3 didn't really work). With the addition of generics to Go, they've been careful to ensure it's fully backwards compatible, so all existing code will still work as is. Major version bumps a…
https://golang.org/doc/go1compat
The fact that they can release generics and NOT bump to 2.0 is a triumph of the language designers and implementers, a testament to how much effort has been put into keeping this commitment.
Re: Expectations for generics in Go 1.18
#68Earlier quoted context omitted.
GC Shape Stenciling, a hybrid of stenciling and dictionaries: https://go.googlesource.com/proposal/+/refs/heads/master/des...
So there's a runtime cost for using generics?
The upside is there is no runtime cost to using generics, the downside is there is significant compile time and link time cost to generics.
Re: Expectations for generics in Go 1.18
#69Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?
Re: Expectations for generics in Go 1.18
#70Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
Oh gosh oh gosh zaglo variables please no