And so Go is one step closer to being a real programming language in many people's eyes.
Saying this about one of the fastest growing languages on the scene right now feels… weird?
Expectations for generics in Go 1.18
81–90 of 209 posts
Re: Expectations for generics in Go 1.18
#82Earlier quoted context omitted.
> How are you thinking of solving this with generics? People can now create Try or Option monads instead of returning the error. This was the one of the reasons anti generics people were anti generics
But that will make error handling more verbose.
Will it?
I can't see it myself, but happy to educate myself.
Re: Expectations for generics in Go 1.18
#83Re: Expectations for generics in Go 1.18
#84Very reasonable caveats for a feature as big as generics. Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.
This is why Java went with type erasure...
Re: Expectations for generics in Go 1.18
#85Re: Expectations for generics in Go 1.18
#86Earlier quoted context omitted.
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.
I believe Rust will warn you if your non-ASCII identifiers are potentially confusing based on this list.
Re: Expectations for generics in Go 1.18
#87Earlier quoted context omitted.
So there's a runtime cost for using generics?
The linked article is a proposal but at least when I tried Go a couple of weeks ago, it did not use that approach and to the best of my knowledge that proposal has not yet been implemented. Instead as of now Go uses the straight forward approach of generating one implementation for every instantiation just like C++ compilers do. The upside is there is no runtime cost to using generics, the downside is there is signif…
The hybrid approach is absolutely implemented: https://github.com/golang/go/blob/master/src/cmd/compile/int...
Re: Expectations for generics in Go 1.18
#88Re: Expectations for generics in Go 1.18
#89And so Go is one step closer to being a real programming language in many people's eyes.
Saying this about one of the fastest growing languages on the scene right now feels… weird?
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.
Re: Expectations for generics in Go 1.18
#90> We expect that some package authors will be eager to adopt generics. If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts. I have a feeling this won't happen.
You're right. I maintain a very large code base in a private repo and a successful open source project. Generics will allow me to clean up a lot of code duplication internally, but given that Go modules are distributed as source code, this would force everyone to use Go 1.18. My plan is to not use generics for quite a while, as it's pointless to have two separate implementations, one for 1.18 and one for < 1.18, whic…
Well for the users, they should be upgrading anyway.
I can't see a situation where someone would mirror your library in and not also have brought, or be bringing in a non breaking language change in the new golang.
The only change management advice I could give, that you'll probably know, would be to roll a month slower than golang.