Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We use C because significant parts of our platform are GStreamer plugins… so C. Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO.


> Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO.

GStreamer is routinely exposed to hostile content in non-sandboxed contexts, such as your traditional Linux desktop; it even works as a browser plugin! Among projects you might want to write in C, GStreamer strikes me as one of the least reasonable. If GStreamer were more widely deployed on phones, it'd be prime attack surface for e.g. regimes attempting to surveil journalists.


"Yeah, but it's not that bad, because like, you can always choose not install the gstreamer-plugins-ugly package."


You can have reasonable C FFI from several other languages. Notably in this context Rust.

Of course if your code is just a thin layer of glue it's not worth it, you'd spend all your time getting into and out of the FFI. But if you write a non-trivial amount of code that actually does something because it isn't just a glue layer, C might actually not be the obvious choice after all.

In the particular case of Rust, somebody else apparently already did this work (not tested, and thus not vouched for): https://crates.io/crates/gstreamer


>We use C because significant parts of our platform are GStreamer plugins… so C.

Ehh..., we have written and deployed gstreamer plugins for a proprietary project at $dayjob which was written in Rust. In the case of gstreamer, they have a plethora of examples for their Rust bindings (I think it's also officially supported).


GStreamer plugins do not in any way dictate C. C++ works fine. As does Zig; and even Rust, with some annoyance.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: