The point the original post is making is that in languages that support asynchrony using callbacks, promises or async/await, they've split the language in two: the "synchronous" and "asynchronous" parts, and reconciling them is a pain. The only languages which avoids this split comfortably are Go and a few other more niche ones (notably BEAM languages like Erlang and Elixir).
This post makes the counter-argument that it's actually a good thing that functions are "colored" differently, as synchronous and asynchronous functions have different execution models, and that should be reflected in the language.
[0]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
I was just put off from doing so because of the author's assumption that everyone in tech is on the same page when this isn't necessarily the case. Many or even most folks "in tech" give little thought to PL design, at least not in the way that would have them read that article, though influential it might have been to some folks in tech that are into these discussions 6 years ago.
This way, others in a similar situation to you get to benefit from GP's explanation. Moreover, GP got to interact with others on this concept.
I'd also wager it took less effort for GP to write this, and then for you to read it, than it would have taken you to do all of it yourself.
Point being, your question led to a very useful answer, and you should be proud, not sorry.
I think the post was great for making people think about this in an abstract way, but I don't think it was meant to reach beyond that mental exercise.
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.
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.
@sync: #00f;
@async: #f00;"Project Loom intends to eliminate the frustrating tradeoff between efficiently running concurrent programs and efficiently writing, maintaining and observing them." [0]
http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...
but Java still have checked exceptions which is also a form of coloring.
If you take a look to the history of Java, checked exceptions was there since the beginning but were weaken several times, first by the introduction of generics+inference (a type parameter can not represent an union of exceptions) then by the introduction of lambdas, the type of a lambda (the function interfaces in Java lingo) used by the standard lib, do not declare checked exceptions.
It's so bad that IOException, the king of checked exception, has two unchecked dual defined by default, UncheckedIOException and IOError that are raised randomly by the new APIs like java.nio.file.Files that do not want to deal with the complexity of checked exceptions.
Java has a checked exception problem but it does not want to recognize it.
BTW, there is another coloring in Java which is primitive vs object, but at least this one is recognized as an issue (see OpenJDK project Valhalla).
But it already works well, you can try it on the project’s branch. But there is no official timeline, it will be ready when it’s ready.
This function is a here is a rough function, this function there is smooth. This function yonder is damp, that one is dry. Careful, you are dealing with a sour function!
Wait, let me open up my blog
I feel old reading these kind of blog posts that assume that we all know what the latest unicorn has been spewing out of its butt. It's like I'm missing out on the greatest debate. On dung.
I'm sure it's valuable debate for those in the know. But this is just how it translates to some of us.
Async/await has been in the discussion for most popular languages (C# and JS first for the masses, Python, Rust, Java, and others) for a decade now.
And the colored functions analogy was a very popular post (and was subsequently referenced and discussed in lots of others).
Besides, HN is not some website about just knowing the core concepts used in the trade. There's Hacker Noon and others for that. HN has always been all about these kind of intra-group discussions.
(edit) Really, everyone should probably start by reading the 1978 papers "on the duality of operating system structures" and "communicating sequential processes", which, when combined with the appropriate background in the continuation passing style compiler transform (which I am pretty sure was also developed around the same time) could have hopefully prevented Ryan Dahl from accidentally causing the callback-hell "dark age" of software engineering from ever happening in the first place ;P.
https://cs.oberlin.edu/~ctaylor/classes/341F2012/lauer78.pdf
For completeness and curiosity maybe. Otherwise one doesn't have to read the "actually-seminal papers" if they already know the concepts from the 40 to 20+ years that followed.
Do physicists need to read the original Einstein or Maxwell if they had read tomes of subsequent course and academic books on the subject, plus modern papers for the later developments?
In any case, I'm pretty sure the author of that post [1] had read at least the CSP papers -- he works on the Dart language team, and has written Game Programming Patterns and Crafting Interpreters, both quite popular books, which have been discussed (as in first page) more than 3-4 times in HN in the past years.
[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-....
I guess maybe the issue in your comment is that my complex sentence with "is more than a bit frustrating" was mis-parsed, as you left off the direct referent of it and then seem to be arguing back at me with the same point I was trying to make with some emphatic irony (I was really hoping to provide three papers all from 1978, but there wasn't a perfect one on continuations)... to re-architect the center a bit:
> ...the idea that I must have read this one random recent blog post [--when I can't imagine this person has read the specific literature I think everyone should have read, as there was an infinite amount of it and a lot of it is equivalent to the rest: the only thing that makes this blog post exciting is almost certainly some kind of recency bias--] is more than a bit frustrating.
We are?