there is an interesting discussion starting here about Generics and use of channels, reflection, and other advanced techniques.
A few quotes:
I think it’s exactly like code generation and reflection and all these other things; I think channels goes in this, too… It’s like, we don’t need to use them most of the time. But when we do need to use them, they are very useful to have. But it’s difficult to figure out when and why you should be using these things, and it takes a lot of time and experience, and while you’re building that time and experience, there’s a cost that you have to pay for having those things in the language… And it feels like we’re adding another big one, that’s like “Okay, now we’re just gonna have to teach a lot of people and figure out as a community how do we wind up writing Go code that still feels like the Go code that we’ve had in the past, with this new feature.” I think that’s just gonna take a lot of time and a lot of effort, and it’s gonna cause a lot of stressful things for people.
Yeah, it’s funny – I mean, I’m guilty of this… When I learned about channels, I loved it, because I saw some example cases where it was used brilliantly… And then I over-used it. And it wasn’t that it didn’t scale in my case, it was that it was hard to follow what was happening. And then I started just using a mutex… And I’ll tell you what - just saying “lock” and “unlock” is very clear; that’s really all you need. It’s kind of perfect.
This perhaps relates to a theme I’m also discovering in the Simple IoT project – simple types and data structures make a lot of sense when it comes to data storage, transmission, and synchronization. Why? Because the core of the system can remain the same and not much needs to change when you add functionality to your system. This is especially important in distributed systems. There are of course limits to this concept, but when used appropriately, it makes life much easier.
I’m a fan of generics. I think that generics are gonna bring some really great things to the language, that we don’t have today, that I’d like to see. Now you can say “Bill, what is that?” I wanna see a package in the standard library that can implement as many of the concurrency patterns that we all have to code ourselves. I think there’s more bugs in Go code today because everybody’s writing their own pooling patterns, fan-outs, other complex things that could be coded by somebody on the language team where you just pass a function or something, and you know that the concurrency pattern is solid. So I’m super excited about that.
The sync.Map - look at the comments around the sync.Map type. You know somebody engineered that to be mechanically sympathetic with the hardware caching system, that you don’t get if you use a regular Go map? Imagine we could put a concrete type to that. I wouldn’t use a regular Go map ever again, because if I’m gonna be doing heavy, heavy map stuff, and I’m gonna get the mechanical sympathies of the caching system with that type, and I get to use a concrete type on top of that? WOOH!
Bill is also optimistic we’ll survive generics:
And I’m not worried about somebody abusing it, because we’ve seen a decade of people abusing channels, and we’re still here. [laughter] So we’re gonna survive.
Lots of good ideas in this epsisode. I purchased Bill’s book which likely contains these ideas – more on that later …