3 ms·
Say channels were always low overhead, two orders of magnitude faster in general or optimized out completely in cases where even that overhead was too much. Wou
by zzzcpan 8y ago
Say channels were always low overhead, two orders of magnitude faster in general or optimized out completely in cases where even that overhead was too much. Would it still make a difference?
I believe performance is only a small part of the problem, channels in Go are just too awkward to use.
- swiley 8y agoI haven't done a ton of go programming but the last small web app I wrote we sent closures over a channel to serialize access to a sqlite database. Channels felt like a nice clean way to handle that.
- perfmode 8y agoThat’s really cool.
- iainmerrick 8y agoYes, sending closures over channels is a very convenient and flexible concurrency framework. In fact it would be handy for all channels to have a standard handler attached, that pulls closures from the channel and executes them. Among other benefits that would mean you didn’t need a separate “go” keyword; to execute a function in the background you just post it to a channel. That’s basically how Java thread pools and Grand Central Dispatch work. The idiom of defining message types that you post to a channel so that you can pull them from the channel and execute them strikes me as boilerplate. What you really want to do is run some code in a particular thread context; so why not just do that directly? Are there useful things you do with channels that can’t easily be done with thread pools?
- weberc2 8y agoThey’re too awkward to throw at every problem, but they are definitely useful for things like serialization. The ergonomics could be improved, however.