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

71–80 of 198 posts

Re: What color is your function? (2015)

#71

Post by vips7L »

zokier wrote: post #27
clintonc wrote: post #23

Earlier quoted context omitted.

My mind went to Java's checked exceptions -- not sure if anyone today believes that coloring is still a good idea.

The problem with checked exceptions afaik was far more in the execution than in the idea itself. And also late 90s-early 00s was different time in general.

Java just makes them hard to use. They're not fully apart of the type system and they're hard to escape when you actually want to panic. Everyone around here praises Rust's result, checked exceptions are the same idea:

    fn someFn() -> Result
    T someFn() throws E
    fun someFn(): T | E  // Kotlin's proposed error unions
Checked exceptions actually compose a little better when you have a function that can throw multiple types:

    T someFn() throws E, F, G
This is like a union type of E | F | G. I don't know about Rust, but most languages won't let you do that over generic types like Result.

The main problem for Java's checked exceptions is just how boilerplatey they are, especially when you can't handle something. In Java if you need to become "unchecked" or panic you need to:

    try {
        someFn();
    } catch (SomeException ex) {
        throw new RuntimeException(ex); // dunno panic
    }
Ideally that would just be:

    someFn()!!!!; // shut up compile panic if this happens

Re: What color is your function? (2015)

#72

Post by dnautics »

sheept wrote: post #68
dnautics wrote: post #58

Earlier quoted context omitted.

I haven't used python recently, but in the days of asyncio it was very much "painful" (to borrow the article's verbage) to use, precisely because of the five criteria in the article.

Painfulness isn't the main issue with colored functions, it only explains why we don't make every function red (async). The main issue is that sync functions can't call async functions, but in Python, you can bypass that restriction with asyncio.run.

Fta

4) Red functions are more painful to call

I guess for me if I reach back to my memory my real problem with asyncio was that it used decorators and wrapping my head around how it was a crazy abuse of generators, completely broke my internal model of how python works (and also how at the time debugging became problematic), and maybe not so much the ergonomics, so strictly speaking a different set of ergonomic problems than in the colored function article

Re: What color is your function? (2015)

#73

Post by steveklabnik »

vips7L wrote: post #71
zokier wrote: post #27

Earlier quoted context omitted.

The problem with checked exceptions afaik was far more in the execution than in the idea itself. And also late 90s-early 00s was different time in general.

Java just makes them hard to use. They're not fully apart of the type system and they're hard to escape when you actually want to panic. Everyone around here praises Rust's result, checked exceptions are the same idea: fn someFn() -> Result T someFn() throws E fun someFn(): T | E // Kotlin's proposed error unions Checked exceptions actually compose a little better when you have a function that can throw multiple type…

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.

Re: What color is your function? (2015)

#74

Post by moritzwarhier »

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 in, for example, Rust or C#.

The article has the same properties that many successful people IRL have: it makes a certain ick very easy to feel and understand, but it doesn't offer much in terms of profound knowledge.

What it does offer though is a perfect spark of discussion, making people who, for example, only know the single-threaded async-await from JS, consider the sheer possibility of other approaches. I am among those people with a limited horizon, presupposing that "knowing" means deep experience to you.

I have some superficial experience with Java physical threads, also with C#, but $job uses JS/TS.

And even in JS, none of this is trivial in my mind.

Consider the deceptively simple question of a kind of "mutex" that enables an async function or method to control concurrency of its own invocation.

The answer to this simple question (queueing promises and clean rejection handling) is already far from trivial, involves the microtask queue, and shows where the mental model of JS-async-await begins to deteriorate.

Re: What color is your function? (2015)

#75

Post by Weebs »

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…

Waiting for async to finish and await are two different things. Async functions essentially have a different calling convention than standard functions. They're either converting your code into continuation passing style, state machines (C#, Rust), or using some sort of stack save+restore usually.

I agree we shouldn't need to `await` everything though. Effects with inference and implicit perform/await is possible

Re: What color is your function? (2015)

#76

Post by jonnytran »

vips7L wrote: post #71
zokier wrote: post #27

Earlier quoted context omitted.

The problem with checked exceptions afaik was far more in the execution than in the idea itself. And also late 90s-early 00s was different time in general.

Java just makes them hard to use. They're not fully apart of the type system and they're hard to escape when you actually want to panic. Everyone around here praises Rust's result, checked exceptions are the same idea: fn someFn() -> Result T someFn() throws E fun someFn(): T | E // Kotlin's proposed error unions Checked exceptions actually compose a little better when you have a function that can throw multiple type…

Some Rust libraries have started to implement unioning multiple error types and handling a subset of them while propagating the rest. But as far as I know, the idea hasn't caught on. Here are the crates I know of.

https://github.com/komora-io/terrors

https://github.com/mcmah309/eros

Re: What color is your function? (2015)

#77

Post by slopinthebag »

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.

The functions are still coloured, just implicitly. IYKYK to spawn a goroutine or not ts.

Re: What color is your function? (2015)

#78

Post by slopinthebag »

I've exclusively used async/await style languages for my entire life and have not once ran into this supposed problem of function colouring. Basically all IO/async work you do requires a context, does it matter if that context is a parameter or a keyword? I don't think so. The author is inventing a problem to rant about.

Re: What color is your function? (2015)

#79

Post by slopinthebag »

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…

> It's an interesting repeat submission to study how HN comments change over time though.

We've had at least a decade of using these async/await languages and discovered function colouring isn't a problem.

Re: What color is your function? (2015)

#80

Post by wtetzner »

zokier wrote: post #26
satvikpendem wrote: post #9

We need algebraic effects in more languages, this solves the function coloring problem. OCaml 5 has them and it seems to be doing quite well, combine that with the semantics of the borrow checker in the form of OxCaml and we might just have an ideal language. I'd like to see algebraic effects in Rust as well but sadly it seems their keyword generics initiative is languishing. Related, one of the former React maintain…

I don't think effects alone solve function coloring problem, in worst case they make it worse because every library can have its own colors

Effects solve it in the sense that the caller can handle the effects to work however they like, making the functions that use the effects more reusable.

E.g., if you install IO handlers that are async and call a function that does IO, it's now an async function.

Post reply on HN