Comment by messe

Comment by messe 17 hours ago

What about it? It gets called without an Io parameter. Same way that a function that doesn't allocate doesn't get an allocator.

I feel like you're trying to set me up for a gotcha "see, zig does color functions because it distinguishes functions that do io and those that don't!".

And yes, that's true. Zig, at least Zig code using std, will mark functions that do Io with an Io parameter. But surely you can see how that will lead to less of a split in the ecosystem compared to sync and async rust?

torginus 14 hours ago

This creates the drill-down issue we see with React props where we have to pass objects around in the call chain just so that somewhere down the line we can use it.

React gets around this with the context hook and which you can access implicitly if it has been injected at a higher level.

Do you know if Zig supports something of the sort?

Reply View 6 replies

throwaway17_17 10 hours ago

I think (and I’m not a Zig user at anything above a hobbyist level) based on what the developers have discussed publically:
React has a ‘roughly’ functional slant to the way it does things and so needs to provide a special case ‘hook’ for a certain type of context object. Zig however is an imperative language that allows for global state (and mutable global state for that matter), which means that there is always a way to access global variable, no hook required. On the other hand, I am relatively certain (almost 100% to be honest) there can not be a context/IO , or any data/variable, passed into a function higher up the call stack and have that propagate to the lower level via implicit inclusion.

Reply View | 0 replies
messe 14 hours 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.

Reply View | 4 replies
- throwaway17_17 10 hours 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.
  
  Reply View | 0 replies
- torginus 4 hours 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?
  
  Reply View | 1 reply
  
  messe 4 hours 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).
  
  Reply View | 0 replies
- rowanG077 8 hours 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.
  
  Reply View | 0 replies

tcfhgj 17 hours ago

> But surely you can see how that will lead to less of a split in the ecosystem compared to sync and async rust?

not yet

Reply View 0 replies