Zig's new I/O: function coloring is inevitable?

Post by tcfhgj » Mon, Jul 14, 2025, 12:44 AM UTC

kristoff_it wrote: post #5

If you want to go down that route, any function that has, or doesn't have, any given resource is colored then. fn foo(db: *Db) !void { ... } fn bar() !void { ... } Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me. The virality of async await is that once you mark a function async, then you can only call it from another async function, which forces you to…

    ...
    // Create the runtime
    let rt  = Runtime::new().unwrap();
    
    // Get a handle from this runtime
    let handle = rt.handle();

    // Execute the future, blocking the current thread until completion
    handle.block_on(async {
        println!("hello");
    });

Post by andyferris » Mon, Jul 14, 2025, 1:23 AM UTC

Post by vlovich123 » Mon, Jul 14, 2025, 1:27 AM UTC

tcfhgj wrote: post #11

kristoff_it wrote: post #5

If you want to go down that route, any function that has, or doesn't have, any given resource is colored then. fn foo(db: *Db) !void { ... } fn bar() !void { ... } Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me. The virality of async await is that once you mark a function async, then you can only call it from another async function, which forces you to…

> The virality of async await is that once you mark a function async, then you can only call it from another async function Rust calling async function in non-async function: ... // Create the runtime let rt = Runtime::new().unwrap(); // Get a handle from this runtime let handle = rt.handle(); // Execute the future, blocking the current thread until completion handle.block_on(async { println!("hello"); }); https://do…

    let result = tokio::task::spawn_blocking(|| {
       5
    }).await;

Post by dwattttt » Mon, Jul 14, 2025, 2:09 AM UTC

n42 wrote: post #7

kristoff_it wrote: post #5

If you want to go down that route, any function that has, or doesn't have, any given resource is colored then. fn foo(db: *Db) !void { ... } fn bar() !void { ... } Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me. The virality of async await is that once you mark a function async, then you can only call it from another async function, which forces you to…

I've been trying to beat this point in and failing. If a parameter type creates "colors", you can extrapolate that to an infinite set of colors in every single language and every single standard library, and the discussion on colors becomes meaningless. Some people are so focused on categorical thinking that they are missing the forest for the trees. The colors are a means of describing an observed outcome -- in Node…

Post by koolala » Mon, Jul 14, 2025, 2:57 AM UTC

dwattttt wrote: post #18

audunw wrote: post #2

I really don’t agree with the idea that this is functional colouring. Then we have to start talking about function colouring in a whole bunch of new contexts like with Zigs explicit passing of allocator. Or any other parameter that needs to be explicitly passed to use some kind of interface. I think we should stick to talking about colouring when there is special calling conventions or syntax, which has the consequen…

> Then we have to start talking about function colouring in a whole bunch of new contexts like with Zigs explicit passing of allocator. That's pretty much where we are though. If you have a function that isn't passed an allocator, and now it needs to call a function that does take an allocator, we're in the same place. Rust's 'async' keyword changes the type of the return value, but you can just write the different r…