3 ms·

> it's a miracle that with the tools we have we are able to write any network applications at all Perhaps it is time to start using a higher-level language? On

> it's a miracle that with the tools we have we are able to write any network applications at all Perhaps it is time to start using a higher-level language? One with a runtime that provides green threads?

rumcajz 9y ago
One hard requirement here is to be able to expose C API. Given the current state of affairs, it's the only way to guarantee that any language runtime will be able to use it. That limits the options quite a lot. I hear it's possible to make shared libraries with Golang nowadays, so that may be an option. Probably Rust, but I'm not sure what's the state of green-threading there. Finally, if you want to go implementing protocols further down the stack (L4, L3) the performance requirements get tighter. So, for example, Golang's GC may rule that language out. Taking all those requirements into account I guess C is still the only option. Maybe Rust one day.
- lmm 9y ago
  Rust doesn't yet have built-in green-threading support (currently you have to rely on a non-core library), but that's the case in C too and will always be so. So I don't understand why you'd regard C as a better choice than Rust?
  - bpicolo 9y ago
    They intentionally removed green threading from Rust long ago, so I would guess they intend to leave it outside core? https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...
    - lmm 9y ago
      I think the intention is that userspace schedulers (event loops) will remain outside of core, but core will potentially contain a task interface and know how to form tasks (but not necessarily offer any way to execute them asynchronously) so that there can be better integration of ownership/borrow checking with async tasks? But I haven't been following that closely.
      - steveklabnik 9y ago
        Yes, this is basically correct. There's an open RFC to add futures to libcore; https://github.com/rust-lang/rfcs/pull/2395 https://github.com/rust-lang/rfcs/pull/2395 But we have no plans on pulling anything more than that in. > so that there can be better integration of ownership/borrow checking with async tasks? It's more about conventions and stability; traits are a great thing to put in the stdlib so the entire ecosystem can use them as an interface.

rumcajz 9y ago

One hard requirement here is to be able to expose C API. Given the current state of affairs, it's the only way to guarantee that any language runtime will be able to use it. That limits the options quite a lot. I hear it's possible to make shared libraries with Golang nowadays, so that may be an option. Probably Rust, but I'm not sure what's the state of green-threading there. Finally, if you want to go implementing protocols further down the stack (L4, L3) the performance requirements get tighter. So, for example, Golang's GC may rule that language out. Taking all those requirements into account I guess C is still the only option. Maybe Rust one day.

lmm 9y ago
Rust doesn't yet have built-in green-threading support (currently you have to rely on a non-core library), but that's the case in C too and will always be so. So I don't understand why you'd regard C as a better choice than Rust?
- bpicolo 9y ago
  They intentionally removed green threading from Rust long ago, so I would guess they intend to leave it outside core? https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...
  - lmm 9y ago
    I think the intention is that userspace schedulers (event loops) will remain outside of core, but core will potentially contain a task interface and know how to form tasks (but not necessarily offer any way to execute them asynchronously) so that there can be better integration of ownership/borrow checking with async tasks? But I haven't been following that closely.
    - steveklabnik 9y ago
      Yes, this is basically correct. There's an open RFC to add futures to libcore; https://github.com/rust-lang/rfcs/pull/2395 https://github.com/rust-lang/rfcs/pull/2395 But we have no plans on pulling anything more than that in. > so that there can be better integration of ownership/borrow checking with async tasks? It's more about conventions and stability; traits are a great thing to put in the stdlib so the entire ecosystem can use them as an interface.