Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Expectations for generics in Go 1.18

groups.google.com

Post reply on HN
Print view View original

71–80 of 209 posts

Re: Expectations for generics in Go 1.18

#71

Post by skybrian »

hota_mazi wrote: post #58

> 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.

Given that every language is different, this is basically reasoning by analogy. Sometimes analogies are useful for explaining things, but they're not a reliable way of determining what will definitely work.

Reasoning by analogy in a sneering way doesn't make it work better.

Re: Expectations for generics in Go 1.18

#74

Post by kodah »

topspin wrote: post #20
Benjammer wrote: post #17

Thank 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?

> oh my god

Definitely the correct response.

Also,

> c++ allows 0-width spaces in variable names. Where's your god now?

Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.

Re: Expectations for generics in Go 1.18

#75

Post by ithkuil »

kodah wrote: post #74
topspin wrote: post #20

Earlier 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?

> oh my god Definitely the correct response. Also, > c++ allows 0-width spaces in variable names. Where's your god now? Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.

Bow to the One whose Name cannot be expressed in the Basic Multilingual Plane

Re: Expectations for generics in Go 1.18

#76

Post by nitrogen »

jchw wrote: post #31
dagmx wrote: post #28

Earlier quoted context omitted.

I'm actually curious if Go would normalize the characters AND if it had used angle bracketd, and make those equivalent to angle brackets? Would he then not have to even change his code? I guess that's a lot of ifs/ands but it's interesting that one could have future proofed their code if their bet on syntax paid off

They're semantically different characters and Go supports multilingual identifiers, so I would not expect normalization to impact this. At most I would expect normalization to simply deal with ordering combining marks and standardizing on composed or decomposed forms of characters (where applicable.)

This got me curious what I'd read about domain names and visual normalization of Unicode, and found this: http://www.unicode.org/Public/security/revision-05/confusabl...

It might be useful for editors and compilers to check for tricky Unicode (lookalikes for common characters, atypical changes in direction, invisible spaces or other formatting control codes, etc.) in this era of copy/paste coding.

Re: Expectations for generics in Go 1.18

#79

Post by infogulch »

mseepgood wrote: post #34
camkego wrote: post #27

Earlier quoted context omitted.

Was the try() proposal for Go error handling? I'm really curious what happened to the proposals for shorter Go error handling, rather than if err!=nil {...}

> Was the try() proposal for Go error handling? Yes, it was the second proposal by the Go team for shorter error handling: https://github.com/golang/proposal/blob/master/design/32437-... > I'm really curious what happened to the proposals for shorter Go error handling The community didn't like it and it was declined: https://github.com/golang/go/issues/32437#issuecomment-51203...

Generics took several iterations from the Go team to finally land on the current (pretty good, imo) design. I might expect error handling to also require multiple tries before it sticks. And we should probably wait for the dust to settle on generics a bit before proposing another design for error handling.

Re: Expectations for generics in Go 1.18

#80

Post by shakezula »

fourseventy wrote: post #66
rustnote wrote: post #48

Earlier quoted context omitted.

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'…

For what it's worth I really like how go handles errors.

I’m with you in this one, Go’s error handling was intuitive to me. It was my first compiled and typed language, though. That might bias my experience.
Post reply on HN