Hacker News Reader

Comment by quelltext | Hacker News Reader

> Most in the tech world are now familiar with the post describing red/blue functions and their downsides, especially in the context of asynchrony.

We are?

View on HN

If you're not, here's the link [0]. It's a pretty influential post, it's introduced whole new terminology of "colored functions" into tech jargon that's starting to become reasonably commonly used. You should familiarize yourself with it if you haven't already.

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

Sorry, I feel bad that you had to write this. It's of course on me to learn about the linked concepts if I want to follow the post.

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.

You should not at all feel bad!

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 for once read that article twice already (once a few years ago, second time today), and I still gained by reading GGP's comment - reading someone else's summary of a topic is a way of quickly validating your own understanding.

Yeah, don't worry about it. People learn new things all the time, I didn't mind writing the comment :)

Don't feel bad, only in tech do we start using a whole new terminology from some random dude's blog post.

As xkcd explains, you are one of the 10000: https://xkcd.com/1053/ so you shouldn't feel bad about it.

I sincerely hope people don't start using just one of the color names at a time. If someone says to me, "That's a red function" I'm going to stop them every single time and ask them which one was red again. It's much clearer and just as easy to say "that's an async function".

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.

So abstract that it took a few paragraphs for me to realize they were talking about a problem I'm intimately familiar with, and already have a pretty decent lexicon for.

Is there an alternative word/concept to "function color" that covers not just sync/async, but also (C++-style) const/non-const functions for example?

Yes, that was a deliberate rhetorical trick. It's works for some audiences, but obviously not all of them.

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.

Can you put a link to your comment in your original blog post? I am really happy to hear from you what you meant, and adding that to the original might help the message.

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?

> Can you put a link to your comment in your original blog post?

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.

I don't see people using the specific colors very often, it's more like "that function is colored differently" or "this language doesn't have colored functions". When used like that, it's a really useful metaphor, it really clarifies what you mean.

I have to say, I dont find it clarifying at all. More like hiding actual information behind term that does not even hint at what it could mean.

  @sync:  #00f;
  @async: #f00;

I still have that reaction every time I hear someone refer to 'green threads'.

So we gonna replace sync and async with colors, whats next?

Texture, smell, taste? Why not?

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 think the idea is to make the concept more general (it's not about blocking/async, it's about adding an additional concept into the language) but then the article is specifically about sync/async so I agree that it's just confusing.

Each function gets a spin, charge and mass.

Just a note, Java will also avoid function coloring very soon with Project Loom.

for sync vs async, yes !

but Java still have checked exceptions which is also a form of coloring.

Yeah, you are right! Though I think not every function coloring is necessarily bad and while Java’s implementation of checked exceptions have some edge cases, I think the idea itself is sound and it’s better to have it supported at a language level instead of recreating it with some meta-language in terms of Maybe/Result types, that loose extra-linguistic information like stack traces (yeah I’m sure they can be included, but that should be the default working).

You can have exceptions like in Erlang, OCaml, C#, Kotlin which all keep the stacktrace without having checked exceptions.

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

The original red/blue article said that Java /didn't/ have function coloring, and that's because it didn't rely on callbacks but rather on threads. Project Loom may in fact be introducing function coloring if I understood the article correctly.

No loom will not be introducing it. It's exactly what the team DOES NOT want. pron even stated it in his "State of Loom" article.

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

I've been hearing this for what feels like 10 years. Are the close to upstreaming now?

It started in late 2017.

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.

Thank you for the clear and concise explanation. That blog post was incredibly annoying to read and imo utterly fails to address an otherwise interesting point.

Despite being in the industry for a decade and authoring a library for async operations, I had never heard of this before.

What, you don't breathe this magical glitter dust in and out every day?

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.

This is not about some unicorn company, or some far-fetched concept.

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.

Right: there is a decade of discussion about this one narrow instantiation of a feature that is itself a mere part the past fifty years of discussion of the general class of thing it is from--coroutines--and an infinite amount of academic material on both that concept and monads--which is the correct mental abstraction to have here--and so the idea that I must have read this one random recent blog post (one which I honestly had heard about it in passing, but without any belief that it was important to anyone or that there was even one specific one that mattered) that was written by someone who probably, ironically, hasn't read all of those actually-seminal papers is more than a bit frustrating.

(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

https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf

>that was written by someone who probably, ironically, hasn't read all of those actually-seminal papers is more than a bit frustrating.

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 would (and in fact kind of do) agree with you... but for the assumption that we have all read this one particular article; like, the premise here isn't that "this is the specific literature you must read", but "why assume I read that when there is so much less to have read? here is what I would have said you should have read, and I can't imagine you did!".

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.

Had the same thought. I've never heard the term coloured functions, and I was certainly browsing HN in 2015.

That sentence triggered my impostor syndrome symptoms, which I felt I was getting under control lately.

There! An impostor! Seize him!

I assumed you also knew COBOL Object standard and the difference between the first and second ADA proposals.

Reply on news.ycombinator.com