💾 Archived View for dioskouroi.xyz › thread › 29421786 captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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

Author: blacksqr

Score: 64

Comments: 17

Date: 2021-12-02 20:10:34

Web Link

________________________________________________________________________________

avl999 wrote at 2021-12-02 21:16:24:

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.

somekyle wrote at 2021-12-02 22:35:19:

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.

thraxil wrote at 2021-12-03 09:01:12:

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.

xh-dude wrote at 2021-12-02 22:16:16:

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.

eikenberry wrote at 2021-12-03 02:21:32:

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.

helge9210 wrote at 2021-12-03 07:37:00:

> few people read the CSP

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

pstuart wrote at 2021-12-03 02:57:07:

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

cmacleod4 wrote at 2021-12-03 17:26:39:

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.

monetus wrote at 2021-12-02 21:01:08:

"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.

avl999 wrote at 2021-12-02 21:20:29:

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