5 ms·
I like slide 41 [0]. What just happened? In just a few simple transformations we used Go's concurrency primitives to convert a - slow
by shurcooL 10y ago
I like slide 41 [0].
What just happened?
In just a few simple transformations we used Go's concurrency primitives
to convert a
- slow
- sequential
- failure-sensitive
program into one that is
- fast
- concurrent
- replicated
- robust.
No locks. No condition variables. No futures. No callbacks.
It's the ability to make these kind of transformations effortlessly at any level, whenever I need to, that make me appreciate choosing Go when solving many tasks.
[0] https://talks.golang.org/2016/applicative.slide#41 https://talks.golang.org/2016/applicative.slide#41
- brobinson 10y ago>No locks. I'm sure the author means there's no explicit locking done by the programmer, but readers should be aware that channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself).
- mappu 10y ago>channels are actually implemented internally using locks (which are 4x slower than using a sync.Mutex yourself). Is that for both buffered and non-buffered channels?
- enneff 10y agoChannels are implemented using locks, but "4x slower" is a meaningless microbenchmark number.
- brobinson 10y agoYou're welcome to benchmark it yourself. I got it from [1] which is a pretty recent comparison. [1] http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ http://www.jtolds.com/writing/2016/03/go-channels-are-bad-an...
- gizzlon 10y agoGP said meaningless, not wrong
- brobinson 10y agoI found switching from channels to plain ol' queues to be an enormous performance improvement in a program sending hundreds of millions of messages, though I do agree in general that most programmers won't need to care about it. The program was a financial model backtesting framework which I ended up rewriting in Rust because Go was simply too slow for what I wanted to do.
- rodrigocoelho 10y agoRelevant: https://www.datadoghq.com/blog/go-performance-tales/ https://www.datadoghq.com/blog/go-performance-tales/
- brobinson 10y agoThis is great, thanks!
- TheDong 10y agoFunny, I've seen more locks in Go than in my time with most other populate languages (excluding C). This is probably because there's no built-in concurrent hashmap or generics to implement one, so it's common to see a lock accompanying every map.