Also, I was one of the readers that managed to interpret your original basically the way you meant it. (One thing that helped is that I had previously read your criticisms of Go.)
I am curious though: what do you think about structured concurrency? It was your post that made me search for a better solution than async/await, and I am of the opinion that structured concurrency might be better. Am I wrong?
I could, but I'm never sure how much work I want to invest in maintaining and updating old content. I try to focus most of my (limited) time on making new stuff and, even though I'm generally a perfectionist, I think it's generally best to just keep moving forward.
> I am curious though: what do you think about structured concurrency?
I'm not familiar with it, sorry. My overall impression is that there is no silver bullet when it comes to concurrency. Humans aren't very good at thinking concurrently, so there's always some level of cognitive inpedence.
At the time I wrote the original article there were a lot of people really excited about the performance of async IO in Node (and JS in general) and were implicitly accepting the async programming style that went along with it. They liked the former so much that it muddled their perspective on the latter. Sort of like how when you go to a shitty diner after an amazing concert and recall the meal as amazing when really it's just because it got wrapped up in the emotional experience of the entire evening.
I had many many discussions of people where I tried to talk about how the async programming model is really cumbersome and their response was "but it makes the app go faster!" We were talking at totally different levels.
It can be really hard to get people to have a clear perspective on something they have an emotional attachment to. By making up a fake language and a made-up concept of function color, it let me show them "hey here's this thing that kind of sucks" without triggering their "but I love async IO in Node!" response.
I had no idea the article would catch on like it did. Something I find interesting about it in retrospect is that because it is kind of strange and abstract, readers take very different things away from it while assuming their interpretation is exactly the one I had in mind. Some folks (like the author here) think it's about effects and static types (even though there is nothing about types at all in the article). Some think it's a love letter to Go (a language I'm not particularly enthused about in general).
Really, I just wanted to talk about the unpleasant user experience of a certain programming style without getting hung up on what underlying behavior the style is attached to.