3 ms·

It doesn't and likely never will. This has been a non-issue for years with Allocator. I fail to see why it will be a problem with IO.

by messe 10mo ago

throwaway17_17 10mo ago
I think the view that it’s a non-issue comes down to familiarity via language usage. I am on the ‘everything explicit all the time’ team and see no issues with Allocator, or the proposed IO mechanism. But, programmers coming from other languages, particularly those with an expectation of implicitness being a semantic and syntactic feature can not envision programming without all of the alleged time saving/ergonomic ‘benefits’. I have had multiple ‘arguments’ about the reasoning advantages, complete lack of time loss (over any useful timeframe for comparison), and long-term maintenance benefits of explicitness in language design. I have never convinced a single ‘implicit team’ dev that I’m right. Oh well, I will keep doing what I do and be fine and will support in whatever ways I can languages and language development that prioritizes explicitness.
rowanG077 10mo ago
Well it's not a "problem" in the sense that it's a blocker. But it's also not an improvement over standard async await in other languages. Which is not bad, don't get me wrong.
torginus 10mo ago
What do you mean by non-issue? You just accept passing it around in every function, and now passing around another param for io as well? Or do you create a context struct and pass that around?
- messe 10mo ago
  > You just accept passing it around in every function In every function that needs to allocate yes. Sometimes, it'll be stored in a struct, but that's rare. And not every function needs to allocate. > and now passing around another param for io as well? Yes. Not everything needs to do Io. You should try reading some idiomatic Zig code. Ghostty would be an example (as would much of the Zig standard library).

It doesn't and likely never will. This has been a non-issue for years with Allocator. I fail to see why it will be a problem with IO.

by messe 10mo ago

It doesn't and likely never will. This has been a non-issue for years with Allocator. I fail to see why it will be a problem with IO.

throwaway17_17 10mo ago

I think the view that it’s a non-issue comes down to familiarity via language usage. I am on the ‘everything explicit all the time’ team and see no issues with Allocator, or the proposed IO mechanism. But, programmers coming from other languages, particularly those with an expectation of implicitness being a semantic and syntactic feature can not envision programming without all of the alleged time saving/ergonomic ‘benefits’. I have had multiple ‘arguments’ about the reasoning advantages, complete lack of time loss (over any useful timeframe for comparison), and long-term maintenance benefits of explicitness in language design. I have never convinced a single ‘implicit team’ dev that I’m right. Oh well, I will keep doing what I do and be fine and will support in whatever ways I can languages and language development that prioritizes explicitness.

rowanG077 10mo ago

Well it's not a "problem" in the sense that it's a blocker. But it's also not an improvement over standard async await in other languages. Which is not bad, don't get me wrong.

torginus 10mo ago

What do you mean by non-issue? You just accept passing it around in every function, and now passing around another param for io as well? Or do you create a context struct and pass that around?

messe 10mo ago
> You just accept passing it around in every function In every function that needs to allocate yes. Sometimes, it'll be stored in a struct, but that's rare. And not every function needs to allocate. > and now passing around another param for io as well? Yes. Not everything needs to do Io. You should try reading some idiomatic Zig code. Ghostty would be an example (as would much of the Zig standard library).