[00:44:07.04] That’s something I think the community is gonna work out naturally. I think a lot of the early practices that we’ve mentioned on this podcast alone in the early days – the abuse of channels, for example, jumping into concurrency and using all the bits and pieces you can, whether your program needs it or not… A lot of these things we’ve sort of worked out of our system, so to speak, and there’s enough material out there to sort of educate – “Try to do this, avoid doing that, for reason X, Y and Z.” Over the years we’ve developed what we call idiomatic Go, basically to adopt certain approaches.
I think yes, in the beginning you’re gonna see an explosion of things that are using contracts, and using all the bells and whistles that generics offer, but I think you’re gonna see a settling down once we’ve shot ourselves in the foot enough times to basically say “Well, this is now basically part of idiomatic Go, as all gophers understand it” kind of thing.
But what I am concerned a little bit about is newbies, folks that are either coming from different languages, or that are learning programming for the first time, and they happen to be using Go to do so – basically, how to teach that concept… Because it requires that you really think about different things in multiple layers, so to speak, to really understand where is this useful.
I think on the Go Blog, the Why Generics post does a pretty good job of introducing “Okay, this is how you would do it today.” You have to have a reverse for a string, a reverse for integers, and this is how generics can help you remove some of that boilerplate.
These kinds of things are gonna be critical for teaching people how to properly use these language features, and I think that’s gonna happen naturally.