Fetching data will definitely be one of the more interesting use cases for the func/proc separation. However, I've got a pattern I've already had success with i

Fetching data will definitely be one of the more interesting use cases for the func/proc separation. However, I've got a pattern I've already had success with in MobX which should translate here: - loading state, response value, and any error are all observable state (wrapped up in a class) - at creation time you pass a lambda that just generates a promise; this function is set to automatically re-run whenever its dependencies change (this will need to be slightly different for Bagel because promises run eagerly; I plan on somehow expressing a "lazy request" or "request spec" as a pure value that can be generated in a pure context and then requested later in a procedural context) I've seen Immer, it's a very cool idea. Right now I'm planning to stick with raw values even for immutable code, though I'm definitely interested in optimizing over that if I can do so transparently > maybe with a language construct that allows mutability only within a certain scope? I've already got a language construct that allows mutability only within a certain scope ;) As for priorities/focus, I would say the order is: 1) Web GUIs 2) Web Servers 3) Games (probably web-based) 4) Everything else (scripts, etc) I have interest in supporting all of these, and I don't think anything I'm doing will be prohibitive of any of them, but when faced with a choice that's good for one at the expense of another, higher priorities win Though I will say: > but for one-off scripts or anything operating in more of a batch mode it seems overly complicated I disagree; I think I can make the reactive model ergonomic enough that it wouldn't be poorly-suited even to casual scripting. It may not benefit you as much there, but I don't think it will hinder you.