4 ms·

Really love the principles set out here. Love the concessions made in order to keep the language simpler. I've been idly considering building an alternative Ru

by skavi 2y ago

Really love the principles set out here. Love the concessions made in order to keep the language simpler. I've been idly considering building an alternative Rust std lib with a shape that reminds me of the capabilities system laid out here. 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. 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.

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
nextaccountic 2y ago
Did you consider using cap_std? https://github.com/bytecodealliance/cap-std https://github.com/bytecodealliance/cap-std Or if it's deficient in some way, contribute to it perhaps The idea behind cap-std is being a stdlib for wasm runtimes in the backend. Wasm is supposed to give us sandboxing for free. It would suck to squander that by not having granular capabilities.
- skavi 2y ago
  This work eschews practicality. The API will be super annoying and no one will want to use it but me. For example, the IO god object is passed to main as a reference rather than by value. I don't think there's any risk of splitting the ecosystem and I don't expect the cap_std project to really be interested in my BS. That said, I did not know about cap_std until you mentioned it. I might steal the thing where all fs functionality is provided as methods on a `Dir`.
  - nextaccountic 2y ago
    You mean, this work like, your own capability-based std? No really I think you should use cap std maybe in a project and see if it meets your needs first

by skavi 2y ago

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

nextaccountic 2y ago

Did you consider using cap_std? https://github.com/bytecodealliance/cap-std https://github.com/bytecodealliance/cap-std Or if it's deficient in some way, contribute to it perhaps The idea behind cap-std is being a stdlib for wasm runtimes in the backend. Wasm is supposed to give us sandboxing for free. It would suck to squander that by not having granular capabilities.

skavi 2y ago
This work eschews practicality. The API will be super annoying and no one will want to use it but me. For example, the IO god object is passed to main as a reference rather than by value. I don't think there's any risk of splitting the ecosystem and I don't expect the cap_std project to really be interested in my BS. That said, I did not know about cap_std until you mentioned it. I might steal the thing where all fs functionality is provided as methods on a `Dir`.
- nextaccountic 2y ago
  You mean, this work like, your own capability-based std? No really I think you should use cap std maybe in a project and see if it meets your needs first