3 ms·
> In my case that was less out of a desire for supply chain security (impossible if I'm just swapping the std lib) and more to discourage side effects from bein
by vacuity 2y ago
> In my case that was less out of a desire for supply chain security (impossible if I'm just swapping the std lib) and more to discourage side effects from being produced deep within the core of program logic.
Although I like capabilities for both purposes, I imagine the latter in isolation is less approachable and marketable. Do you also count heap allocations as side effects to be externalized?
> WRT the rejection of async, has there been any consideration of a more general feature like generators or coroutines? Resumable functions are a really nice way to write state machines. I don't expect those to go out of style.
Async/await in Rust is just stackless coroutines (which are just glorified state machines) with some async IO-specific conventions on top, so if we get "just" coroutines it will be more than enough.
- skavi 2y ago> Do you also count heap allocations as side effects to be externalized? I’ve gone back and forth on heap. I admire Zig’s handling of allocation failures, but I’d also like to use Rust’s alloc lib. I’m currently leaning towards allocation and printing to stderr being available under any context. > Async/await in Rust is just stackless coroutines Yup, it was actually through Rust’s async that I learned about stackless coroutines. There’s a really fun rust crate [0] that implements effects with Rust’s nightly coroutine feature. [0]: https://github.com/rosefromthedead/effing-mad https://github.com/rosefromthedead/effing-mad