Earlier quoted context omitted.
I’m sorry but I just don’t enjoy functional Scala.
Paraphrasing someone else: then keep enjoying the disfunctional one :-P
Haha you got a good chuckle out of me on that one.
Zig's new I/O: function coloring is inevitable?
41–50 of 83 posts
Re: Zig's new I/O: function coloring is inevitable?
#42One way or another, I like how this is implemented. Explicitely passing dependencies like this, with a tight syntax, makes things easy to understand and write. I haven't written any Zig but these demonstrations give me strong vibes of how I felt when I picked up Go more than 10y ago.
I mean, isn't it how it's always been, up until JS/python "single threaded" runtimes became what most people had ever encountered?
Re: Zig's new I/O: function coloring is inevitable?
#43i never got warm with this async/await style of calling things. i much more prefer using threads/fibers/protothreads instead. Sure you have to be more expicit on creating and controlling these and also passing around data may get more complex, but at least they do not gloss over the underlying problems async and await tries to cover up
Re: Zig's new I/O: function coloring is inevitable?
#44If 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…
Well said. Honestly I don't understand this "function coloring argument" at all in zig's context. Function is the smallest unit of logic. And function parameter is the fundamental way to control it.so, in theory, __A function parameter is the smallest possible design choice you have to control async vs sync__ There is no way to reduce it further. As you need to encode this somehow, otherwise it will be implicit and v…
> in theory, __A function parameter is the smallest possible design choice you have to control async vs sync__
So we are just going to forget Go exists?
Re: Zig's new I/O: function coloring is inevitable?
#45I believe Zig's new I/O is neither colored nor not colored, instead the design is orthogonal to that. You won't be able to make code magically async by just swapping the implementation of Io, instead you'll need some kind of runtime that allows functions to wait without blocking OS threads. Depending on how this is implemented (if it's possible at all) you'll have colored functions or not.
Re: Zig's new I/O: function coloring is inevitable?
#46One way or another, I like how this is implemented. Explicitely passing dependencies like this, with a tight syntax, makes things easy to understand and write. I haven't written any Zig but these demonstrations give me strong vibes of how I felt when I picked up Go more than 10y ago.
I mean, isn't it how it's always been, up until JS/python "single threaded" runtimes became what most people had ever encountered?
Single threaded is a bit old, it wasn't until recently that no one had multiple cores outside HPC.
Re: Zig's new I/O: function coloring is inevitable?
#47With Zig I/O you can call i/o functions from non-i/o functions and non-i/o functions from i/o functions. In the analogy of “What color is your function”, you can call blue functions from red functions and red functions from blue functions. The pernicious viral nature of function coloring doesn’t apply.
> With Zig I/O you can call i/o functions from non-i/o functions and non-i/o functions from i/o functions
Yes, but you would either create a new std.Io just for that, or use a global/semi-global std.Io from somwhere else
Re: Zig's new I/O: function coloring is inevitable?
#48I am actually really excited about this. The issues I've had with function colouring had to do with trying to compose code using (or expecting) blocking effects with those using async effects in NodeJS - if one library has a higher-order function that expects a non-async function and you have functionality which is provided to you as async, it can be very difficult to plumb them together! And if it's the other way ar…
> much like Haskell
I have not mentioned this in the post, but it's surprising how monadic I/O operations are, including async/await approach
And it is certainly in FP land to pass I/O as parameter, because everything is a function
Re: Zig's new I/O: function coloring is inevitable?
#49Earlier quoted context omitted.
> so e.g. making it easy to call an Io function from a non-Io function "removes" the colouring problem. Exactly. In golang (which is also a cooperatively multithreaded runtime if I understand correctly), calling a function that needs IO does not infect the callers type signature. In async rust, and in "async param" zig, it does.
Another poster up thread identified the exact problem: async/await contexts are not first-class values, they are second class citizens. If they were values then you could just stick the context in a struct/class and pass that around instead, and avoid having to refactor call chains every time something changes. It's their second class status that forces the "colouring" into the function signature itself at each point…
> async/await contexts are not first-class values
Because async/await are not values, they are ways to run/structure your code. That's why they are so infectious. If you don't want the division the only solution is to make everything of one kind. Languages like C make everything sync/blocking, while languages like Go make everything async.
Re: Zig's new I/O: function coloring is inevitable?
#50If 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…
> No, because you would just pass that extra argument around and nothing else would have to change.
> Semantically, passing std.Io to every function is no different from making every Node.js function async and returning a promise. Zig shifts function coloring from blocking/non-blocking choice to io/non-io.
> Complains are about how inconvenient it is to work with [blocking and non-blocking function handling] differences
"Extra argument" in this case is not much different from "extra async keyword", because you can only run I/O functions when having std.Io in scope.