Had a long running bet that NCIS would be cancelled before Go got generics. Now it looks like I must eat my words.
eh, Mark Harmon left before Go got generics.
Expectations for generics in Go 1.18
101–110 of 209 posts
Re: Expectations for generics in Go 1.18
#102Re: Expectations for generics in Go 1.18
#103Earlier quoted context omitted.
I would say, many people also look down on much more popular languages, such as PHP. Go is still an absolute niche language, even more niche than languages like Scala or R.
Niche in your niche perhaps, but there's a lot of code in the wild written in Go. Hell, all the modern devops tools are written in Go (Docker, k8s & co.) Meanwhile, as a non Java programmer, I've never seen a Scala app. I know about R, but nothing on my PC is written in it. Agreed that PHP is massive in comparison to all of them.
> Meanwhile, as a non Java programmer, I've never seen a Scala app.
One widely known Scala application is Kafka. Some parts of it are in Java, but actual core is still mainly Scala afaik.
Re: Expectations for generics in Go 1.18
#104Finally catching up with modern times.
Re: Expectations for generics in Go 1.18
#105Earlier quoted context omitted.
It's funny how codegen has become widespread in Golang to work around its deficiency.
Codegen is a super flexible and versatile tool, and simply having a strong generics feature does not mean you can avoid it: at $DAYJOB we use codegen even for C++ for e.g. grpc/openapi types, generating rapidjson streaming unmarshallers, etc not even counting Qt's moc/uic.
I understand and agree, I've run many a Java project that used codegen to emit Protobuf/Avro IDLs as types.
But Go having actual generics, and accordingly removing some need for codegen, is not a bad thing at all.
Re: Expectations for generics in Go 1.18
#106Thank 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?
I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct.
Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon.
I wonder how people on vim/emacs deal with situation like this.
Re: Expectations for generics in Go 1.18
#107Earlier 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?
I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.
The rust compiler warns when it encounters confusable symbols like that. Not sure about other languages.
Re: Expectations for generics in Go 1.18
#108Earlier quoted context omitted.
But that will make error handling more verbose.
Speaking as a user of languages that have exactly this, it can’t possibly be any worse than the situation in Go right now.
Other languages have an additional zoo of language syntax besides generics to make monadic error handling bearable, which Go doesn't have.
Re: Expectations for generics in Go 1.18
#109Earlier 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?
I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.
On VSCode, I use the Gremlins extension which highlight all those suspicious characters.
Re: Expectations for generics in Go 1.18
#110Earlier 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?
I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.
It's similar when online editors try to be clever and replace a straight " with a fancy one (like in Word), really annoying.