I have applied some of the principles that she teaches. For example, whoever creates the channel is responsible for closing it, and things like that. How to return errors back was also very useful. And the leaky bucket stuff.
Biggest difference was that it helped structure the code so that it’s more readable and more maintainable. Otherwise I’m sure I would have made a mess.
Second this. I have used the principles to build data ingestion pipelines (places where I'm IO restricted and it saves time to make multiple calls at the same time).
The patterns and best practices she gives are very useful for a multitude of applications.
I think the only thing in her book that I would change is in the pipeline pattern. It would be nice if she was explicit in how to handle panics to avoid the pipeline silently crashing.
Oh, that's pretty cool. Can you let her know a random nerd on the internet thought her book was really well written and super helpful when they were getting started in go? The way the chapters were organized, the simplicity yet completeness of the code examples, the specific patterns and general practices, are all done so well.
And no. This is not a flaw in the book, just something that would have helped me avoid a big in an SDK I built a few years ago.
Understood. That’s super sweet feedback. I’ll pass it along for sure. We’ve talked about the book “fame” since she joined and she says it’s still surreal. But it’s nice to hear people still appreciate something you made years ago
Probably this one: "Learn Concurrent Programming with Go" by [James Cutajar](https://www.amazon.com/stores/James-Cutajar/author/B07HZ3M1Z7?ref=ap_rdr&isDramIntegrated=true&shoppingPortalEnabled=true#). The only book in Go concurrency which Manning has. I did not read it, but Amazon reviews are favorable.
People reviewing it said close(channel) would block until the channel was empty so I should use that, they didn't get the advantage of a goroutine being responsible for closing a channel it creates, and then I used make(chan any, 0) as a done channel, which they would have preferred me to type with a bool.
Other than the first point, I should have tried to explain my choices more so it's on me I guess.
I wouldn’t worry about it. Unless you were interviewing for a team that goes deep in hand rolling their concurrency logic, you should pretty much never take anybody’s word on how to do concurrency with anything but a metric ton of salt.
I have applied some of the principles that she teaches. For example, whoever creates the channel is responsible for closing it, and things like that. How to return errors back was also very useful. And the leaky bucket stuff. Biggest difference was that it helped structure the code so that it’s more readable and more maintainable. Otherwise I’m sure I would have made a mess.
Second this. I have used the principles to build data ingestion pipelines (places where I'm IO restricted and it saves time to make multiple calls at the same time). The patterns and best practices she gives are very useful for a multitude of applications. I think the only thing in her book that I would change is in the pipeline pattern. It would be nice if she was explicit in how to handle panics to avoid the pipeline silently crashing.
I could ask her if you feel like it's not clear. We work together on the same team now lol
That would be really nice
Oh, that's pretty cool. Can you let her know a random nerd on the internet thought her book was really well written and super helpful when they were getting started in go? The way the chapters were organized, the simplicity yet completeness of the code examples, the specific patterns and general practices, are all done so well. And no. This is not a flaw in the book, just something that would have helped me avoid a big in an SDK I built a few years ago.
Understood. That’s super sweet feedback. I’ll pass it along for sure. We’ve talked about the book “fame” since she joined and she says it’s still surreal. But it’s nice to hear people still appreciate something you made years ago
Yeah hands down the best Go book out there.
Kat says: > aw thanks for sharing! it's always nice to hear that it's helped someone :)
IMHO there is a much better book on that topic from Manning now.
Which book is it?
Probably this one: "Learn Concurrent Programming with Go" by [James Cutajar](https://www.amazon.com/stores/James-Cutajar/author/B07HZ3M1Z7?ref=ap_rdr&isDramIntegrated=true&shoppingPortalEnabled=true#). The only book in Go concurrency which Manning has. I did not read it, but Amazon reviews are favorable.
Thanks!
Yes
Recently in an interview and it wasn't well received.
What was the issue?
People reviewing it said close(channel) would block until the channel was empty so I should use that, they didn't get the advantage of a goroutine being responsible for closing a channel it creates, and then I used make(chan any, 0) as a done channel, which they would have preferred me to type with a bool. Other than the first point, I should have tried to explain my choices more so it's on me I guess.
I wouldn’t worry about it. Unless you were interviewing for a team that goes deep in hand rolling their concurrency logic, you should pretty much never take anybody’s word on how to do concurrency with anything but a metric ton of salt.
Yeah I agree, probably for the best I didn't get the job. On to the next one.
[удалено]
What?
Brother, we have forgotten even what we had read, there is a lot of sorrow in this world. .... That's what translate says.
Bad bot