How and why Daily is using Rust for our WebRTC APIs
1–10 of 30 posts
Re: How and why Daily is using Rust for our WebRTC APIs
#2What is `daily-core` actually doing? It is signaling code?
Have you evaluated webrtc-rs yet? I haven't keep up to date with mediasoup, but I saw they have a rust effort. Have you evaluated that yet?
Seems possible to drop lots of C++ dependencies :)
Re: How and why Daily is using Rust for our WebRTC APIs
#3What is `daily-core` actually doing? It is signaling code? Have you evaluated webrtc-rs yet? I haven't keep up to date with mediasoup, but I saw they have a rust effort. Have you evaluated that yet? Seems possible to drop lots of C++ dependencies :)
We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now.
`daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.
Re: How and why Daily is using Rust for our WebRTC APIs
#4What is `daily-core` actually doing? It is signaling code? Have you evaluated webrtc-rs yet? I haven't keep up to date with mediasoup, but I saw they have a rust effort. Have you evaluated that yet? Seems possible to drop lots of C++ dependencies :)
We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.
Are there use cases for calls with so many participants?
Re: How and why Daily is using Rust for our WebRTC APIs
#5What is `daily-core` actually doing? It is signaling code? Have you evaluated webrtc-rs yet? I haven't keep up to date with mediasoup, but I saw they have a rust effort. Have you evaluated that yet? Seems possible to drop lots of C++ dependencies :)
We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.
Have you considered releasing your Rust bindings for libwebrtc separately, either as open source or as another commercial product? I could have really used that for a desktop application I started developing a few months ago. In the absence of such bindings, I went with Electron instead, reluctantly. And no, I don't think your high-level API would be a good fit; what I'm doing with WebRTC is too custom.
Edit: Also, webrtc-rs doesn't work for me either; AFAIK, it doesn't yet have enough of the media stack, including hard stuff like echo cancellation.
Re: How and why Daily is using Rust for our WebRTC APIs
#6Earlier quoted context omitted.
We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.
Are there use cases for calls with so many participants?
Company earnings calls with analysts? Livestreams?
Re: How and why Daily is using Rust for our WebRTC APIs
#7Even if it sounds like it makes sense, something tells me that these (not just this one, all of these kinds of 'why x and y is happening') are really after-the-fact rationalizations after some dev or devs decided to engage in a pet project that would have happened even if it had no sensible justifications at all.
Re: How and why Daily is using Rust for our WebRTC APIs
#8Even if it sounds like it makes sense, something tells me that these (not just this one, all of these kinds of 'why x and y is happening') are really after-the-fact rationalizations after some dev or devs decided to engage in a pet project that would have happened even if it had no sensible justifications at all.
Why do you say that?
Re: How and why Daily is using Rust for our WebRTC APIs
#9> This means that whenever we decide to throw the switch to multi-threaded WebAssembly, essentially no code needs to change as all of our logic is already written in a concurrent-friendly manner. We simply reap the benefits of a multi-threaded runtime on the Web.
In a multithreaded wasm app, do all threads have equal access to the DOM, or is it more like JS where there is a UI thread which can access all APIs and a bunch of worker threads which can only access a more limited set of APIs?
If the latter, has anyone sought to expose that constraint to the Rust type system? e.g. via a capabilities object that's neither Sync nor Send
Re: How and why Daily is using Rust for our WebRTC APIs
#10[deleted]