Hacker News new | ask | show | jobs
by cmrdporcupine 3849 days ago
They're fine concepts, but... On the little project I was tasked with using Go with at Google I got slapped down by the readability reviewers for using them. I think this is an interesting construct, but not sure that community really knows how to use them well?

Erlang at least is consistent on this -- it has that hammer well tuned and isn't afraid to pound nails with it.

2 comments

Mmmm I'm puzzled. I don't think we are consulting the same community... Goroutines are everywhere in all the main go projects. Goroutines and channels are one of the main reasons Go exists.
"Readability reviews" at Google are somewhat notorious for imposing fairly arbitrary style choices extremely rigidly, for instance 80 characters per line (woe betide you if even one line in a 5000 line patch is 81 characters...). It doesn't sound so surprising to me that the people behind such a process might have decided that one of Go's primary selling points is 'confusing', given that the Go authors appear to believe their colleagues can't handle a brilliant language!
It's quite possible. After my experience with Go code reviews internally at Google, though, I am not eager to go back. I'd work on a project if I was paid to do it, but I wouldn't start one or advocate for it.
He said at Google not the community. I wouldn't doubt there is a difference.
I'm pretty sure at Google they know why they created Go, why they're using Go, and so on... The assumption that Google reviewers had something against goroutine puzzles me a bit. Maybe the problem was not about goroutines, but about how they were used... I don't know, I'm guessing...
Yea, not having OTP to create proper structure, instead having goroutines and channels created and destroyed all over the place, really hurts readability.

But OTP isn't really possible either because Go lacks links and monitors.

Plus not being asynchronous and no distribution (wouldn't want to go over the network with sync channels anyway)...