On 22.10.2025 19:07, Rémi Denis-Courmont via ffmpeg-devel wrote:
Le keskiviikkona 22. lokakuuta 2025, 16.07.36 Itä-Euroopan kesäaika Timo
Rothenpieler via ffmpeg-devel a écrit :
C++ can be used as-is, since it can read all our headers just fine.

FFmpeg public headers are C++-compatible and, frankly as a C developer, I find
that annoying. Not sure about Zig, but Rust does not care about your C headers
and won't require C programmers to muck with their header files to appease
rustc.

Or more accurately, it gives you the choice to use or not to use bindgen to
parse the C headers. And frankly, you are more often than not better off not
using it.

Using anything else needs extensive and constant porting work, that then
will also make future iterations of internal APIs much harder if not
impossible, forcing people who have zero experience with the other
language to learn it, just to enhance the C side of things.

Plus, most of these fancy modern languages are not just a programming
language, but they also want to play package-manager, which then forces
all of its downstream users to babysit a ton of package version, which
largely don't give a damn about stable APIs.

C++ sucks just as badly as Rust to make stable APIs/ABIs. In the end, you end
up having to expose a C interface, whether you're using C, C++, Zig, Rust or
anything else. And you'll have to do that forever, since C is the lingua
franca of system-level programming interfaces.

So we then need to constantly monitor all those dependencies for bugs
and issues, and potentially a fix for one pulls in breaking API changes,
which then need to be addressed and backported.

FUD much? How exactly do any other language relieve you from the problem of
tracking bugs in dependencies?

They allow a distributor to do it centrally, and don't burden it onto every single developer.

Cargo gives you the *choice* of pinning or not pinning the versions through
the lock. FFmpeg should *probably* not pin anything and just specify minimum
version requirements. And it'll be the exact same dependency hell that we
already have (or don't have - that's subjective) with C. Nothing to see here.

Given that API stability is far from a given in that world, not pinning anything does not sound like a good idea.
I'd rather just not enter that dependency hell at all.

Attachment: OpenPGP_0xD85AAA6874B7507E.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to