Tcl library for Go-style concurrency based on Communicating Sequential Processes | Hacker News Reader

Tcl library for Go-style concurrency based on Communicating Sequential Processes

github.com

64 pointsblacksqr17 comments

I'll be slightly contrarian here... the Go concurrency model is not the panacea and channels are overused. It works brilliantly for certain types of usecases (straightforward producer consumer usecases). But unfortunately in the early years of the language there was so dogma pushing people to solely lean on channels and actively avoid traditional concurrency primitives like mutexes and condition variables. Some of that dogma still exists although nowadays "channels are a shotgun that can hurt you" opinion is starting to be more prevalent in the community.

I have seen Go code that twists and contorts itself to solely use channels when straightforward mutexes would have made the code easier to understand and reason about.

Libraries like this and channels should only be seen as another tool to consider when writing concurrent software rather than treating them like the panacea for concurrent software.

A subtlety I’m ok with here … channels are a a language primitive but, in terms of runtime, an opinionated composition of data and concurrency semantics; the opinions give the runtime some privilege to do some nice things without a lot of effort when using channels. The misuse of channels in a general sense tends to equate to factoring out of some of the elements composed into the channel primitive.

It feels like a lesser sin to use channels in clever ways to recreate mutexes or other patterns than the other way around. But it’s definitely true that they are juiced up to make tradeoffs that are morally wrong for some things.

Yes, overapplying directional advice is a problem, and channels aren't always the right choice, but mutexes/cond vars/atomics have always been part of Go and they've always been listed as viable options, just not usually the best choice for high level coordination. To quote the go1 Effective Go on channel-based interaction:

  This approach can be taken too far.  Reference counts may be best done
  by putting a mutex around an integer variable, for instance.  
  But as a high-level approach, using channels to control access makes it easier
  to write clear, correct programs.

I'm sure somebody has been banging a "Go programs should never use mutexes" drum, but it hasn't ever been the position of the Go team that channels are a panacea or that mutexes _shouldn't_ be used, as far as I've ever seen.

Agreed. I've been writing Go since like 2011 and even when I started there was plenty of emphasis on channels as just one of the options along with mutexes and a sense that channels were easier to make correct, but mutexes were easier to make efficient. If someone else got the impression that channels were pushed exclusively, I guess they were watching different talks and reading different documentation than I was.

IMO the problem was that to few people read the CSP paper and don't use it properly. They keep wanting to do standard procedural programming just using channels instead of data flow models or others that work well with CSP.

TLDR; CSP is a great model for concurrency but barely anyone uses it.

> few people read the CSP

I've read it after inventing similar concept and implementing it on top of Python+Redis. So embarrassing.

Liberal use of channels is code smell that the developer is new to Go.

    "This concurrency model may also be seen as a generalization of Unix named pipes where processes and pipes correspond to coroutines and channels."

This is in keeping with tcl, bash, and glue languages - I love this. I'm about to go looking for it, but if anyone can point me to a good reference on Go's concurrency model or it's best practices I would be much obliged.

This is the best reference I found: https://gobyexample.com/goroutines

Keep reading the next thing until they stop talking about concurrency.

This post might be the most straightforward starting point: https://go.dev/blog/pipelines

Effective Go is often thrown around to newcomers such as myself.

https://go.dev/doc/effective_go#concurrency

And go by example, of course: https://gobyexample.com/goroutines

The chapter on channels in Concurrency in Go https://www.oreilly.com/library/view/concurrency-in-go/97814... is a must read for anyone looking to write concurrent code in Go. There are many "rules" you need to follow with channels to avoid shooting yourself in the foot that I haven't seen summarized in blog posts/official go docs

I recommend rob pike's talk on Go concurrency patterns.

Great presentation with a lot of examples: https://youtu.be/5zXAHh5tJqQ

I've used examples from this presentation at work

I guess I should drop Tcl's author view on concurrency and threading,

https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/...

And the HN discussion related to it, https://news.ycombinator.com/item?id=17297325

Last update to this was 6 years ago and the documentation links are dead. However from the man page file it seems that this flavour of coroutine cannot be used in the same program as native Tcl coroutines. This would make it useless to me and I suspect to many other people who have an interest in this area.

Time to start writing tcl, folks!

Reply on news.ycombinator.com