Hi, Le 23 février 2025 23:30:03 GMT+02:00, "Tomas Härdin" <g...@haerdin.se> a écrit : >lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont: >> Le perjantaina 21. helmikuuta 2025, 20.02.16 UTC+2 Tomas Härdin a écrit : >> > The above said, I'm not against Rust. It has some nice properties. But >> > it does not seem very "stable" so far. Perhaps this has changed in >> > recent years.. >> >> IME, it's become very usable for user-space code. Bare metal still pretty >> much >> requires unstable features, but that's not a problem for FFmpeg. > >I mean more in terms of ABI, and having to have cargo install specific >versions of the Rust compiler and so on.
Why? The ABI will never be fully stable. Zero-cost abstractions just don't lend themselves to an ABI. But what is stable is not going to just break in a future version. We could settle for Rust edition 2024 and not depend on any specific compiler version, AFAICT. >> > If we're in the habit of allowing other languages I'd be in favor of >> > allowing C++, so that we can make use of the STL containers rather than >> > rolling our own. >> >> Yikes. Rust is actually way saner for type-generic programming than C++. > >No doubt, but STL is still miles better than rolling our own >containers. But STL is not worth switching to C++ for. If the goal is to enable a language with significantly improved static safety, without compromising on performance (especially no GC) and optimisability, then Rust is pretty much the only option at the moment. If the goal were to provide a nicer language to work with rather than improving safety, then maybe Zig would be better than Rust. But I don't see a scenario where C++ can be justified/worthwhile. >Anyway, rather than shoehorning Rust into this codebase it might make >more sense to contribute to NihAV instead. But only if it has a sane >parsing framework That makes sense if the goal is to publish and forget, but otherwise I doubt that NihAV will ever be relevant "in the field". That being said, I think Rust would make much more sense for decoders and demuxers than for filters and ML stuff. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
