Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How and why Daily is using Rust for our WebRTC APIs

daily.co

Post reply on HN
Print view View original

21–30 of 30 posts

Re: How and why Daily is using Rust for our WebRTC APIs

#21

Post by kwindla »

yolo69420 wrote: post #7

Even 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.

FWIW we did two pretty extensive proof-of-concept prototypes (one in pure C++ and one in Rust) before choosing Rust for this project. I, personally, thought that we would choose C++. I'm a big "choose boring technology" advocate. [1]

In other words, we tried hard to document a lot of before-the-fact rationalizations to go with the inevitable after-the-fact rationalizations. :-)

[1] https://mcfunley.com/choose-boring-technology

Re: How and why Daily is using Rust for our WebRTC APIs

#22

Post by Sean-Der »

mwcampbell wrote: post #5
kwindla wrote: post #3

Earlier 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.

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, w…

You should help out with the gaps in the media stack! That is the only way it will get better :) I don't believe echo cancellation is a hard problem either. I don't know the specific details, but I have heard this argument so many times.

People told me that unless you were a developer at a big company you can't build DTLS, SCTP and RTP Congestion Control either. Maybe the community implementations aren't as good yet, but I think it is a tortoise vs hare.

Re: How and why Daily is using Rust for our WebRTC APIs

#23

Post by [deleted] »

kwindla wrote: post #21
yolo69420 wrote: post #7

Even 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.

FWIW we did two pretty extensive proof-of-concept prototypes (one in pure C++ and one in Rust) before choosing Rust for this project. I, personally, thought that we would choose C++. I'm a big "choose boring technology" advocate. [1] In other words, we tried hard to document a lot of before-the-fact rationalizations to go with the inevitable after-the-fact rationalizations. :-) [1] https://mcfunley.com/choose-boring-…

[deleted]

Re: How and why Daily is using Rust for our WebRTC APIs

#24

Post by Matthias247 »

monocasa wrote: post #16
kjsthree wrote: post #15

Earlier quoted context omitted.

The question still stands though. Does each individual worker have its own bridge to JS? If so it’s just a constant race condition between them.

Yes, sort of. They can all call into JS, but that JS context is single threaded and serializes access. There can be races depending on what assumptions you make, but those races can't cause memory unsafety of the type usages of Sync and Send are trying to prevent.

How would it serialize? That means potentially interrupting any other JavaScript or WASM code running on the main UI thread and executing other JS code there? That seems kind of against what JavaScript is (100% singlethreaded).

I assume if it’s even possible, it might execute the code only if the main thread is not executing any events - which happens only once per eventloop iteration.

I guess what is happening is that worker can call into JS, but can not access the DOM or anything else living on the main thread. They have to send messages to the other thread, just as JavaScript workers would need to do.

Re: How and why Daily is using Rust for our WebRTC APIs

#25

Post by monocasa »

Matthias247 wrote: post #24
monocasa wrote: post #16

Earlier quoted context omitted.

Yes, sort of. They can all call into JS, but that JS context is single threaded and serializes access. There can be races depending on what assumptions you make, but those races can't cause memory unsafety of the type usages of Sync and Send are trying to prevent.

How would it serialize? That means potentially interrupting any other JavaScript or WASM code running on the main UI thread and executing other JS code there? That seems kind of against what JavaScript is (100% singlethreaded). I assume if it’s even possible, it might execute the code only if the main thread is not executing any events - which happens only once per eventloop iteration. I guess what is happening is th…

Because it's structured as WASM popping a normal event on the event queue of the normal JS main thread. There's no 'now run JS on the WASM thread but with DOM access'.

Re: How and why Daily is using Rust for our WebRTC APIs

#26

Post by fosefx »

Matthias247 wrote: post #24
monocasa wrote: post #16

Earlier quoted context omitted.

Yes, sort of. They can all call into JS, but that JS context is single threaded and serializes access. There can be races depending on what assumptions you make, but those races can't cause memory unsafety of the type usages of Sync and Send are trying to prevent.

How would it serialize? That means potentially interrupting any other JavaScript or WASM code running on the main UI thread and executing other JS code there? That seems kind of against what JavaScript is (100% singlethreaded). I assume if it’s even possible, it might execute the code only if the main thread is not executing any events - which happens only once per eventloop iteration. I guess what is happening is th…

> 100% singlethreaded

You can (and should) use Web Workers[1], those run off the UI thread, but also don't have access to the DOM.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Re: How and why Daily is using Rust for our WebRTC APIs

#27

Post by yolo69420 »

NoraCodes wrote: post #8
yolo69420 wrote: post #7

Even 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?

it's just kind of obvious from looking at the distribution of these kinds of posts. lots of people posting blogs about why they use x and y new technology with these objectively good reasons to do so, and then two years later everyone jumps on another pet project hype train.

it seems like these reasons to do something mysteriously only stay valid for the short period of time in which a technology has some kind of hype status and quickly fades when people realize that it's actually not that much improvement in practice and the hassles (training devs in new language, worse language ecosystem etc.) aren't actually worth it.

Re: How and why Daily is using Rust for our WebRTC APIs

#28

Post by regexident »

Sean-Der wrote: post #22
mwcampbell wrote: post #5

Earlier quoted context omitted.

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, w…

You should help out with the gaps in the media stack! That is the only way it will get better :) I don't believe echo cancellation is a hard problem either. I don't know the specific details, but I have heard this argument so many times. People told me that unless you were a developer at a big company you can't build DTLS, SCTP and RTP Congestion Control either. Maybe the community implementations aren't as good yet,…

> You should help out with the gaps in the media stack! That is the only way

As it happens I am the author of the audio-buffer and constraint-algorithm implementations in webrtc-rs/media: https://github.com/webrtc-rs/media/commits?author=regexident

So even though we are not using webrtc-rs in Daily today, we are (or at least I am) contributing to it, in hopes of it becoming a feasible option at some point.

Re: How and why Daily is using Rust for our WebRTC APIs

#29

Post by regexident »

Sean-Der wrote: post #2

What 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 :)

> Have you evaluated webrtc-rs yet?

Vincent here, fellow dev at Daily, working on daily-core and Daily for iOS. :)

We did evaluate webrtc-rs, but we found that it simply isn't yet were it would need to be in order to be a realistic replacement for libwebrtc.a today. As a matter of fact I am a member of the webrtc-rs org (https://github.com/orgs/webrtc-rs/people), having contributed the audio-buffer and constraint-algorithm implementations so far (https://news.ycombinator.com/item?id=31000261).

I personally have high hopes for being able to make the jump at some point. Just alone being able to toss the monstrous `build.rs` that currently ties ninja/gn (libwebrtc), cmake (libmediasoupclient), clang (our own bridging code) and bindgen (for header imports) together and makes things work across multiple platforms would almost be worth it for me. With Rust implementations of mediasoupclient and webrtc none of this hassle would be necessary. In pure Rust stuff just works.

Re: How and why Daily is using Rust for our WebRTC APIs

#30

Post by NoraCodes »

yolo69420 wrote: post #27
NoraCodes wrote: post #8

Earlier quoted context omitted.

Why do you say that?

it's just kind of obvious from looking at the distribution of these kinds of posts. lots of people posting blogs about why they use x and y new technology with these objectively good reasons to do so, and then two years later everyone jumps on another pet project hype train. it seems like these reasons to do something mysteriously only stay valid for the short period of time in which a technology has some kind of hyp…

I'd be interested to see follow-up posts by these companies later. As an example, my former employer started using Rust in 2017 and is still happily and productively using it today, but they only put out a blog post when they started, and they haven't talked about it since.
Post reply on HN