Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What color is your function? (2015)

journal.stuffwithstuff.com

Post reply on HN
Print view View original

101–110 of 198 posts

Re: What color is your function? (2015)

#101

Post by Jtsummers »

hutao wrote: post #99
Jtsummers wrote: post #54

Earlier quoted context omitted.

There are no function colors in Go in the way being discussed. Every function can be spawned as a go routine, every function can spawn go routines.

Go (and other language with threads) implicitly run inside the "async IO monad." In the function color analogy, what this means is that all functions are red, and the "ordinary" function call corresponds to "await" in languages such as JavaScript or C#. Async/await is one implementation of cooperative concurrency , where the programmer must explicitly annotate the points where a context switch may occur. However, one…

>> Go language praised in the article still has red and blue functions

This is my principle point of disagreement with the OP comment in this thread. Your response is either not meant for me, or is meant to agree with me, but I'm really not sure but you write:

> In the function color analogy, what this means is that all functions are red

and

> while Go does not distinguish between async and sync functions

Which was my point. Go does not have the function color problem (around sync/async) because it does not color its functions that way.

Re: What color is your function? (2015)

#102

Post by pverheggen »

amiga386 wrote: post #51
rendaw wrote: post #30

I really don't like this article. It has a catchy, profound-sounding title that people bandy about to argue against stuff they don't like. All functions, even non-async functions, are colored. In any large system codebase you'll have functions that can only be called in certain situations, with the right setup, whatever, and if you're lucky this is communicated by types but regardless those restrictions can't be avoi…

I'm fairly sure the author was making reference to the famous article What Color Are Your Bits? https://ansuz.sooke.bc.ca/entry/23 which is even more abstract, because some large numbers are coloured "legal" and the same large numbers are coloured "illegal", based on where you got the numbers from . All functions are not coloured, don't try to wriggle out of it by generalising. This article is a specific complaint ab…

Agreed. Every time this article makes the rounds, people get hung up on the syntax, and not the performance considerations discussed towards the end. Nystrom wrote a whole book on interpreters, and his main criticism here is the big mess of chained closures this makes at runtime, compared with pausing/resuming green threads.

Re: What color is your function? (2015)

#103

Post by nemothekid »

sheept wrote: post #65
nemothekid wrote: post #61

Earlier quoted context omitted.

Java's checked exceptions fit the 5 criteria: 1. It either `throws` or it doesn't 2. If the function `throws` you have to wrap it in try/catch, or make your function `throws` 3. Your function is `red` if it `throws` the same exception. 4. see (2) 5. See the FileReader class in core. Now, C++ exceptions might not satisfy all of these, but the problems CheckedExceptions were meant to solve still exist in C++ and as a r…

#3 is not satisfied, as you noted in #2. You can call `throws` methods from non-`throws` methods by wrapping the call in a try catch, and `throws` methods can call non-`throws`. There isn't an exclusivity asymmetry like there is for JavaScript async.

That only applies to Javascript, which, is mostly only red functions anyways (there are no blocking apis in javascript). Javascript doesn't have the coloring problem in the way Python or Rust has it.

In Python, you can wrap the call with asyncio.to_thread, in rust with tokio::spawn_blocking.

Re: What color is your function? (2015)

#104

Post by hutao »

Jtsummers wrote: post #101
hutao wrote: post #99

Earlier quoted context omitted.

Go (and other language with threads) implicitly run inside the "async IO monad." In the function color analogy, what this means is that all functions are red, and the "ordinary" function call corresponds to "await" in languages such as JavaScript or C#. Async/await is one implementation of cooperative concurrency , where the programmer must explicitly annotate the points where a context switch may occur. However, one…

>> Go language praised in the article still has red and blue functions This is my principle point of disagreement with the OP comment in this thread. Your response is either not meant for me, or is meant to agree with me, but I'm really not sure but you write: > In the function color analogy, what this means is that all functions are red and > while Go does not distinguish between async and sync functions Which was m…

I was not looking to disagree with your point, I only wanted to make additional commentary. Sorry if my comment came across the wrong way.

I do think "There are no function colors in Go in the way being discussed," versus "all functions [in Go] are red" are two slightly different ways of formulating the same set of facts, and the distinction between them is insightful, so that was what I wanted to touch upon. Namely, I wanted to point out that there is an "implicit" color within the programming language itself.

Re: What color is your function? (2015)

#105

Post by nemothekid »

dnautics wrote: post #63
nemothekid wrote: post #61

Earlier quoted context omitted.

Java's checked exceptions fit the 5 criteria: 1. It either `throws` or it doesn't 2. If the function `throws` you have to wrap it in try/catch, or make your function `throws` 3. Your function is `red` if it `throws` the same exception. 4. see (2) 5. See the FileReader class in core. Now, C++ exceptions might not satisfy all of these, but the problems CheckedExceptions were meant to solve still exist in C++ and as a r…

Ok, sorry it's been about 20 years since I last javad IIRC you didn't have to declare exceptions in your function signatures. However, wrapping in try/catch seems to violate #3. Try catch is not a heavy lift of a seam between red and blue To be fair, #3 seems to have shades of grey. In some pls, you can call an async function from a sync one by wrapping it in a whole damn event loop system. Should that count?

Your question just kicks the can down the road. The problem with the article, to me, is the author doesn't want to accept a certain amount of complexity and has erected arbitrary road blocks.

To you, a "whole damn event loop system" is too high a price to pay, but try/catch is not. The complexity of exceptions is invisible to you. However there are certain environments (e.g. FFI) where I dont want "the whole damn exception runtime".

Re: What color is your function? (2015)

#107

Post by simonask »

sheept wrote: post #36
qihqi wrote: post #16

Colored functions are good. It reflects the language design on signaling what is important, and what are the properties it want the writer to pay attention. Other examples of colored functions: * Haskell: pure function and non-pure (IO monads) looks different. * Rust: unsafe functions (or block) requires special markers.

Rust unsafe functions aren't a good example of colored functions because it doesn't exhibit the main issue brought up in the article, that one color can call the other but not the other way around. In Rust, unsafe code can call safe code, and safe code can call unsafe code. Calling unsafe code in safe code requires an explicit unsafe block, but that's fairly normal and not a hack to get around function coloring. A be…

I don’t really see how declaring an unsafe block is materially different for the purposes of this discussion than, e.g., entering an async runtime.

It is code you need to write, tradeoffs you need to weigh, invariants you need to keep.

Re: What color is your function? (2015)

#108

Post by soulofmischief »

moritzwarhier wrote: post #74
rendaw wrote: post #30

I really don't like this article. It has a catchy, profound-sounding title that people bandy about to argue against stuff they don't like. All functions, even non-async functions, are colored. In any large system codebase you'll have functions that can only be called in certain situations, with the right setup, whatever, and if you're lucky this is communicated by types but regardless those restrictions can't be avoi…

It's an interesting repeat submission to study how HN comments change over time though. Regarding content, I agree with you. Async/Await is an amazing paradigm in JS for simplifying callback patterns and non-blocking suspense. In other programming languages, there exist other intriguing paradigms that are more elegant and emphasize other aspects of "async"; my prime example 2 would be Erlang, but I am not experienced…

While non-trivial in several ways, there are standard Web APIs such as Web Workers, Web Audio API, OffscreenCanvas, SharedArrayBuffer, etc. which help to construct modern, multi-threaded applications in JavaScript. Hopefully today, any experienced JavaScript-focused web developer should be experienced with more async paradigms than just async/await.

I think these APIs address real issues, but it also makes the entire stack more complex when integrated language support might be better for some features. But, keeping things separate does mean JavaScript as a language is fairly portable and backwards-compatible, if you ignore Web API support. Still, a lot of other languages feel more batteries-included and have more elegant multi-threaded async fundamentals.

Re: What color is your function? (2015)

#109

Post by vips7L »

steveklabnik wrote: post #91
vips7L wrote: post #86

Earlier quoted context omitted.

Wouldn't you lose a little compile time safety a little by returning the interface, like catching Exception? i.e. as types you don't know about get introduced the compiler won't stop bad things from happening: catch (Exception ex) { switch (ex) { case SomeException1 se1 -> .. case SomeException2 se2 -> .. default -> throw new IllegalStateException(ex); // panic } }

Depends on what you mean by "safety," what this is really about is open vs closed set. An interface means that there's an open set of things that could be returned, whereas an enum is a closed set. Which one is correct for you depends on your code and requirements. It's true that if you return an open set of things, you'll have to handle cases you didn't explicitly account for.

I just meant knowing what errors can be happen at compile time vs unchecked errors flying about. I personally am not a fan of the compiler not stopping me when a new error type is introduced. Correctness is probably the better word.

Re: What color is your function? (2015)

#110

Post by wasmperson »

cogman10 wrote: post #67
wasmperson wrote: post #64

IMO the function coloring problem was solved with async/await. This article was posted before Javascript's async/await syntax cleaned up that ecosystem, so the author is only guessing when they say it doesn't fix the issue. It did fix the issue, and now function coloring isn't really a problem. If async/await doesn't solve the coloring problem, then neither do threads. Why would you ever need to start a thread to inv…

No, I think you don't understand the problem. This article is about async/await. The function coloring problem arises when you have async functions. Regular functions can't call async functions. You have to hoist them into async functions in order to do that. Threads do solve this problem because they are just regular functions being called by other regular functions. They don't require the entire function stack to b…

> This article is about async/await.

It is not. It tries to address async/await part-way through, but it does so without the context of 10 years of successful async/await usage in javascript, the language it's criticizing.

> Threads do solve this problem because they are just regular functions being called by other regular functions. They don't require the entire function stack to be `async` in order to work.

This is fixating on syntax: it would be trivial for all functions to simply be `async` by default and for all calls to an `async` function to automatically `await`. This might "fix" the coloring problem as you describe it but I argue wouldn't meaningfully change anything.

Post reply on HN