I hope this gets merged into the upcoming Yocto `kirkstone` LTS release branch, since that branch will use the same pinned version for years to come. The previous `dunfell` LTS release branch provided Go 1.14, which can no longer build the latest versions of many projects.
Go 1.18
171–180 of 614 posts
Re: Go 1.18
#172Now time to update interface{} usage and shift to any . $ gofmt -r 'interface{} -> any' -l **/*.go Replace -l with -w to write.
well there goes my Hacktoberfest idea
Re: Go 1.18
#173I hope open source Go code in the wild remains easy to read and understand. Generics look cool, despite this possible downside.
I have already started having trouble understanding open source code using generics. I can see the upsides of having generics, but have lost the enthusiasm with which I used to browse Go code. I am still a junior engineer, so maybe it will get better with time.
Every abstraction tool will get misused, especially early on. I bet the Go community will figure out how ways to mitigate that in the long run, given it’s culture around readability.
Re: Go 1.18
#174There is also a new set of FAQs on generics:
Re: Go 1.18
#175The general excitement about generics on this thread makes me uneasy.
Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.
Re: Go 1.18
#176In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional
type Optional[T any] struct {
value *T
}
func MakeOptional[T any](value *T) Optional[T] {
func (o* Optional[T]) Unwrap() (T, error) {
2. There's no error here, the situation is equivalent to a missing key in a map - it's enough to return a bool.
Here's my implementation so far: https://gist.github.com/Mawr-BF2/0a60da26f66b82ee87b98b03336.... Only thing I'm not sure about is whether the JSON serialization methods are necessary.
Re: Go 1.18
#177I will forever miss old Go :-(
Re: Go 1.18
#178My favorite feature is a tiny, couple line bug fix that I pushed hard to get included during the feature freeze. Full details here, but a summary is below: https://github.com/golang/go/issues/51127 For the past ~8 years, many hundreds of people reported on GitHub - and likely many multiples more have encountered and not reported - a program that didn't work with the error "cannot unmarshal DNS..." This error seems to…
I read through the whole issue thread. I admire your firmness on pushing through while at the same time maintaining professional and analytical tone in your responses. To me it is a good example how I'd imagine most open-source issue discussions should go. I understand both sides, and trade offs taken. Nice work.
Although the "your best bet to get a desired change through isn't via a private call with a maintainer." comment directed at you made me chuckle.
Re: Go 1.18
#179Honestly I think this will make the overall programming experience worse.
Re: Go 1.18
#180Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.
I'm curious why you say fortunately? I find it to be quite a down side that type parameters are missing. In fact it's quite confusing, because there is nothing that indicates a constrained interface can't be used in place of a regular one (until you try it). Personally, I think they should be included simply because they are a side effect of the generics syntax and it's much more confusing without. Also, they increase clarity and type safety, which are two of Go's main advantages.
Also, type parameters were supposed to be included, but were dropped because it made the implementation more complex.