3 ms·

> But here, we’re in C, so there is nothing there's your problem. I mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing is as g

by pilif 7y ago

> But here, we’re in C, so there is nothing there's your problem. I mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing is as good as or even better than `other_project_vector` and `some_library_vector` or maybe even `some_other_vector` All of which were implemented by various projects out of necessity because the language they chose doesn't have such an essential data structure in its standard library and because the culture around the language values NIH more than anything else. Remind me again, why C is a good thing and not a liability these days?

rom1v 7y ago
> I mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing I agree, that's a waste of time I would have preferred to avoid. The lack of a such basic structures is something I really dislike in C. > Remind me again, why C is a good thing and not a liability these days? Ubiquity, portability, performance, interface with other languages…
- cyphar 7y ago
  There was quite a bit of interest in getting Rust parsers into VLC a few years ago[1], is there any update on this -- will we ever see core VLC code using Rust? [1]: https://www.youtube.com/watch?v=YTy_JOxGOd4 https://www.youtube.com/watch?v=YTy_JOxGOd4
  - rom1v 7y ago
    Personally, I'd love to :) One annoying point is that the core API, used by the modules, can change at any time (the modules are updated along with the API). If there are Rust bindings for the core API [1], every API change must be reflected in Rust (and in modules written in Rust). This is problematic. [1] https://www.youtube.com/watch?v=YTy_JOxGOd4&t=875 https://www.youtube.com/watch?v=YTy_JOxGOd4&t=875
- pilif 7y ago
  > interface with other languages… Many languages that compile to native code allow you to export functions in a way that they can be called from other C code. This means you'd write your actual code in whatever language you want (possibly one that does have a generic vector in its standard library - but I guess these days that's anything but C) and then you'd just export a usable-by-C interface so other languages still get to interface with your implementation.
leetcrew 7y ago
c and c++ are still great choices when you care more about performance than correctness. a media player doesn't (or shouldn't at least) modify any of my essential data, so the worst it can really do is crash every now and then. for a program like vlc, mild instability is not a bad trade-off if it means less dropped frames on old computers.
- wgoodall01 7y ago
  I wouldn't agree with that---media players are often fed untrusted content from the Internet, so a security issue in a shared media player API can be critical. See the Android StageFright vulnerability from a few years back. Writing it in C for a marginal performance gain just isn't worth it.
- pilif 7y ago
  > a media player doesn't (or shouldn't at least) modify any of my essential data Ask the Android team about the stagefright exploit. Media players provide a huge attack surface. They are constantly exposed to untrusted files which are also very enticing for users to open (as opposed to, say, some spreadsheet) Yes. A media player normally doesn't modify your essential data, but when it's written in an unsafe language, it is very likely to do so one way or another.
- lodi 7y ago
  I would argue the opposite; a media player is one of those applications where you just need "good enough" performance. Good enough to play 4k/8k/whatever content, without dropping any samples/frames, without causing my fans to spin up. After that point I would much rather have rock solid stability and security than more performance.
swsieber 7y ago
> why C is a good thing and not a liability these days? That's the wrong question. The question should be: "If I rewrite this in a different language, will it be a net-benefit? If so, just how long will it take to reap said benefit?" The trade-offs add a lot of nuance to that question and make it a harder choice.

by pilif 7y ago

rom1v 7y ago

> I mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing I agree, that's a waste of time I would have preferred to avoid. The lack of a such basic structures is something I really dislike in C. > Remind me again, why C is a good thing and not a liability these days? Ubiquity, portability, performance, interface with other languages…

cyphar 7y ago
There was quite a bit of interest in getting Rust parsers into VLC a few years ago[1], is there any update on this -- will we ever see core VLC code using Rust? [1]: https://www.youtube.com/watch?v=YTy_JOxGOd4 https://www.youtube.com/watch?v=YTy_JOxGOd4
- rom1v 7y ago
  Personally, I'd love to :) One annoying point is that the core API, used by the modules, can change at any time (the modules are updated along with the API). If there are Rust bindings for the core API [1], every API change must be reflected in Rust (and in modules written in Rust). This is problematic. [1] https://www.youtube.com/watch?v=YTy_JOxGOd4&t=875 https://www.youtube.com/watch?v=YTy_JOxGOd4&t=875
pilif 7y ago
> interface with other languages… Many languages that compile to native code allow you to export functions in a way that they can be called from other C code. This means you'd write your actual code in whatever language you want (possibly one that does have a generic vector in its standard library - but I guess these days that's anything but C) and then you'd just export a usable-by-C interface so other languages still get to interface with your implementation.

leetcrew 7y ago

c and c++ are still great choices when you care more about performance than correctness. a media player doesn't (or shouldn't at least) modify any of my essential data, so the worst it can really do is crash every now and then. for a program like vlc, mild instability is not a bad trade-off if it means less dropped frames on old computers.

wgoodall01 7y ago
I wouldn't agree with that---media players are often fed untrusted content from the Internet, so a security issue in a shared media player API can be critical. See the Android StageFright vulnerability from a few years back. Writing it in C for a marginal performance gain just isn't worth it.
pilif 7y ago
> a media player doesn't (or shouldn't at least) modify any of my essential data Ask the Android team about the stagefright exploit. Media players provide a huge attack surface. They are constantly exposed to untrusted files which are also very enticing for users to open (as opposed to, say, some spreadsheet) Yes. A media player normally doesn't modify your essential data, but when it's written in an unsafe language, it is very likely to do so one way or another.
lodi 7y ago
I would argue the opposite; a media player is one of those applications where you just need "good enough" performance. Good enough to play 4k/8k/whatever content, without dropping any samples/frames, without causing my fans to spin up. After that point I would much rather have rock solid stability and security than more performance.

swsieber 7y ago

> why C is a good thing and not a liability these days? That's the wrong question. The question should be: "If I rewrite this in a different language, will it be a net-benefit? If so, just how long will it take to reap said benefit?" The trade-offs add a lot of nuance to that question and make it a harder choice.