What's Coming in Go 1.22 - Daniel Martí - November Gophers 2023

A summary of all language, toolchain, standard library, and performance changes coming to Go 1.22, due in Feburary 2024.
Presented at November Gophers 2023

[@NotSexualAtAll]

Really great talk. Not only in content but in presentation. You're an excellent public speaker and this was awesome.

[@md2704]

Great talk! I'm falling more and more in love with the language. Hopefully they add enums soon.

[@dermuschelschluerfer]

you already have const with iota operator for that

[@angeloceccato]

Enums like Discrimination Unions are really tasty but I don't think they're coming anytime soon

[@perc-ai]

Need switch

[@nixoncode]

don't use go, clearly!

[@billhammond6209]

Great!

[@Alberto_Cavalcante]

Great presentation. Thanks for sharing!

[@nixoncode]

loved the talk

[@TorstenBronger]

I find func iterators difficult to explain and just syntactic sugar. It is sad that the people in the Go team who have kept Go boring become fewer and fewer.

[@bebobauomy1265]

If it could be fun and simple in the Sametime, why not? For really Go is ugly we will not going to lose anything if it is more fun to use.

[@TorstenBronger]

I don’t find func iterators simple.

[@bebobauomy1265]

@@TorstenBronger Sorry I was taking in general, the language itself still so mush simple compared to other languages, and yes func iterations are not simple, I feel like they are trying to put everything inside a small box, instead of making more keywords, they are just pushing any new feature inside what they have already, but the language sill simple and ugly tho.

[@angeloceccato]

I think the confusion caused by the lack of a standard way of iterating is more problematic. Ultimately, iterators are a well-known feature in any other ecosystem, i think worth the trade-off...

[@TorstenBronger]

@@angeloceccato One of my problems is that I basically know iterators from Python and understood them immediately, whereas the realisation in Go is still magic to me.

[@andrewdunbar828]

I thinked he said "freezed". "Intuhgers" does indeed sound really weird.

[@wWvwvV]

I still don't understand why a nil interface might not be equal to nil. There must be a reason to handle it like that. In Go there are pointers pointing to 0 but also inbuilt data structures also containing pointers like structs like strings, maps, slices. A string cant be nil, but maps and slices can. An interface is a struct. It has a pointer to it's value and a type. If there is no value but a known type, the interface is not nil anymore. The value of the interface is nil. the type is known. This makes the interface not nil. And if you ask the interface for the value it says nil and causes a panic. You have to know that, especially in error handling where 'error' is an interface.

[@wWvwvV]

Coroutines in Go sound beautiful. It has nothing to do with threads. It's a function with internal state that you can call over and over to give results. Like a generator in Python. One of the misuses in Go was/still is using channels to give back results. A channel does messenging between threads. Don't use channels in any high performance algorithms. They need two threads. What I can also say. Don't use Go maps in an API. APIs that only use arrays and slices are much more simple than with maps.

[@Thoer]

`slices.Concat` feels weird. why is it better than `append(slice1, slice2...)`? and if it's not, why have two ways of doing this?

[@pudgebooster]

Backward compatibility. If there is a better way to do something they will add it but will keep the old way

[@Thoer]

@@pudgebooster seems like my own answer is not visible for some reason. `slices.Concat` can take a variable number of slices, `append` will only concatenate 2 slices.

[@alihammadshah]

stop fkn with gopath, fkn hell man go is becoming like node as time passes. gone are the days when you could create a directory in gopath and start writing. go modules should have been made around gopath, this is fkd up, didn't they promise backward compatibility for ever.