Hacker News Reader

Comment by OskarS | Hacker News Reader

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

View on HN

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

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.

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.

Reply on news.ycombinator.com