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

91–100 of 198 posts

Re: What color is your function? (2015)

#91

Post by steveklabnik »

vips7L wrote: post #86
steveklabnik wrote: post #73

Earlier quoted context omitted.

Rust makes you define an enum of E, F, and G, but also provides a conversion API so you can pass any of the three and it feels like it does, at least at the site of returning the error. It also provides an error interface so sometimes you don’t need the enum, if all the types return that interface.

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.

Re: What color is your function? (2015)

#92

Post by Terr_ »

skybrian wrote: post #87
Terr_ wrote: post #66

Earlier quoted context omitted.

> Like async, the biggest problem with exceptions were the ergonomics. I know it's not a popular take, but I prefer the idea of Checked Exceptions over unchecked ones [0], and suspect current opinions would be vastly different if Java had shipped with some sweet syntactic sugar for: "If an exception that is of kind A or B or C occurs, automatically throw another checked exception X with the original exception as a ca…

The problem with Java's checked exceptions is that it has too many kinds of exceptions to choose from and they're overly specific. Compare with Go, which has a single error interface and had it from the beginning, so it's used everywhere. Returning a new kind of error is always a local change, unless it's a function that didn't previously report errors at all. Type systems permit either standardization or fragmentati…

> too many kinds of exceptions to choose from

I don't understand, why would you need to pick a checked exception? It's the dual or mirror of feeling paralyzed over a return-type because there are "too many kinds of Object to choose from."

If you're writing a CrystalBall class with a gaze_deeply() method, you'll probably return your own VisionResult (extends Object) unless it throws your TooCloudedException (extends Exception).

When someone else writes a wrapper or higher-level layer that uses your code, then it'll be up to them to convert or wrap those results and exceptions into something suitable for their level of abstraction.

> Returning a new kind of error is always a local change

One of my axioms here is that return-values and checked-exceptions are two sides of the same architectural type-system coin. While I'm not familiar with Go, that sounds like something that would be a symptom of bad architecture if it occurred for return values.

In other words, suppose all Java methods always returned Object [0]. That would also ensure that a new return type is "always a local change" to the compiler, but I think most developers would be rightly horrified if they came across code that worked that way.

[0] Let's ignore Java primitives for now.

Re: What color is your function? (2015)

#93

Post by tardedmeme »

jcranmer wrote: post #47
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…

What I like least about this article is that it's completely soured the entire context of asynchronous programming. Invariably, any time someone discusses design of an async functionality, function coloring is brought up, with almost no analysis as to how it applies and why it's a good or bad thing. (Ironically, I probably see more in-depth analysis these days as to why this article isn't apropos than why it is when…

What I like most about the article is that it drove the conversation to realising that async is just a poor reimplementation of threads, and put the focus back on how to do threads faster.

Re: What color is your function? (2015)

#94

Post by tardedmeme »

jcranmer wrote: post #69
dnautics wrote: post #57

Earlier quoted context omitted.

what I like least about this article is how people seem to just substitute some other, usually theory, notion of what function coloring is to elide the argument (usually to excuse their favorite PL) without actually RTFA. The article is about ergonomics, not PL theory. > Exceptions cause function coloring do they? Do they? 1) Every function has a color 2) The way you call a function depends on its color 3) You can on…

Let's go through the list: > 1) Every function has a color Every function either throws an exception to indicate failure or doesn't. There's actually several different function colors available here, based on how failure is indicated: throwing exception, aborting the process, composite return value, error code return value, global errno-like variable, error code as a parameter, .... > 2) The way you call a function d…

Failing is a color, but throwing an exception isn't. An exception-throwing computation can easily embedded in a computation that doesn't throw - you can catch and return null, etc. But very rarely can a computation that may fail be part of a computation that may not fail.

Re: What color is your function? (2015)

#95

Post by dnnddidiej »

jcranmer wrote: post #47
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…

What I like least about this article is that it's completely soured the entire context of asynchronous programming. Invariably, any time someone discusses design of an async functionality, function coloring is brought up, with almost no analysis as to how it applies and why it's a good or bad thing. (Ironically, I probably see more in-depth analysis these days as to why this article isn't apropos than why it is when…

I am so happy I have never heard anyone IRL say colored functions. It would annoy me. The concept is interesting but like all engineering it is a trade off. In Node amd Go you don't get a choice anyway. In C# you might choose based on performance thinking of thread pools etc IIRC.

When programming in Node I find in practice async and "colored functions" no issue especially with async await. Except for performance issues they come with sometimes but not at a programming level.

Re: What color is your function? (2015)

#96

Post by dnnddidiej »

tardedmeme wrote: post #93
jcranmer wrote: post #47

Earlier quoted context omitted.

What I like least about this article is that it's completely soured the entire context of asynchronous programming. Invariably, any time someone discusses design of an async functionality, function coloring is brought up, with almost no analysis as to how it applies and why it's a good or bad thing. (Ironically, I probably see more in-depth analysis these days as to why this article isn't apropos than why it is when…

What I like most about the article is that it drove the conversation to realising that async is just a poor reimplementation of threads, and put the focus back on how to do threads faster.

Probably you are right except for some pathological scenarios. Threads and green threads and models where you have have 10000s of threads and not even hit the cardio fat burning zone.

Re: What color is your function? (2015)

#97

Post by overgard »

I think a few things are simultaneously true here:

1. async/await is a huge improvement over callbacks.

2. doing asynchronous programming through callbacks has always been a messy hack, primarily coming from languages that couldn't/wouldn't do real concurrency in their runtimes and async/await just papers over it without fixing the fundamental problems

3. threads are a lot more elegant from a language design standpoint and a lot more powerful, but..

4. .. I would much rather fuss with what color my function needs to be than deal with the average concurrency bug that results from threads.

Re: What color is your function? (2015)

#98

Post by tabwidth »

enragedcacti wrote: post #18
bre1010 wrote: post #10

I wish the key word was instead dontawait and was used inversely to how await is used. 99% of the time I'm using an async function, despite however slow it is, there's nothing for my code to do but wait for it to finish. But if for some reason I would like the next line of code to run before the current one is done, I'll let you know . Like, why can't my sync function await something asynchronous? If it has to lock u…

> Like, why can't my sync function await something asynchronous? The answer, at least for Python, is that it is an intentional limitation because the alternatives introduce some quite bad trade-offs. Option 1: your awaited promise goes into the main async event loop. This is bad because it means that your single-threaded sync function now needs to be thread-safe, and so does any sync code that calls your sync functio…

It may depend on the runtime giving you a sync wait that doesn't deadlock the loop you came from. In JS you just can't. `dontawait` would need V8 to be a different VM.

Re: What color is your function? (2015)

#99

Post by hutao »

Jtsummers wrote: post #54
viktorcode wrote: post #52

If I understand correctly, Go language praised in the article still has red and blue functions, only now they the colours are handled implicitly, and you as a programmer reading the code will have harder time guessing which is which on the call site.

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 can imagine a program transformation that marks every function as async, and makes every function call an await. After making that transformation, the async/await annotations would no longer be necessary. The end result is pre-emptive concurrency, where the runtime may potentially interrupt the active thread at any function call.

To make another analogy, Haskell requires all IO actions to run in the explicit IO monad, while most languages (C, Java, JavaScript, etc.) do not distinguish between "pure" and "impure" functions. Therefore, C, Java, and JavaScript could all be said to implicitly run in the IO monad.

Async IO is also an instance of a monad. In JavaScript, all async functions must run inside the explicit async IO monad, while Go does not distinguish between async and sync functions. Therefore, Go implicitly runs in the async IO monad. This is similar to the aforementioned distinction between cooperative (made explicit to the programmer) and pre-emptive (handled implicitly by the runtime) concurrency.

In fact, Eugenio Moggi, the PL theorist who realized monads could describe programming languages, was not looking for a programmer-facing abstraction. Rather, he was trying to describe the "implicit" monad in a programming language's semantics (such as the IO monad in most programming languages, or the async IO monad in Go).

Re: What color is your function? (2015)

#100

Post by [deleted] »

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…

[deleted]
Post reply on HN