4 ms·

Yeah, and you know, the Rust guys are actually doing some great work on making a language that solves some of these problems without giving up the advantages th

Yeah, and you know, the Rust guys are actually doing some great work on making a language that solves some of these problems without giving up the advantages that make C programmers choose C. Meanwhile, you are just being snarky on a message board while using a whole stack of software that was built by the programmers whose work you are criticizing.

gcr 13y ago
This list of criticism is copied verbatim from the article's list of fixed bugs, not composed directly by the OP.
- scott_s 13y ago
  The snark, however, is wholly original.
  - npsimons 13y ago
    Considering it's entirely predictable and I've seen ones just like it a million times before, no, it's not. Relevant xkcd, esp. panel 2: https://xkcd.com/568/ https://xkcd.com/568/ "You will never find a programming language that frees you from the burden of clarifying your ideas."
ajross 13y ago
Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero. So perhaps the "some of these problems" is perhaps a bit spun. Rust looks great for apps and middleware. I don't see ffmpeg or x264 (both of which are implemented with significant amounts of architecture-specific machine code -- an environment where neither C nor Rust is going to be able to help avoid the kind of bugs we're talking about) jumping ship any time this decade.
- haberman 13y ago
  Yeah I don't think it's likely either. But it's a lot more likely than Modula-2, Ada, or any of the other languages that the OP would be arguing of in favor of C. OP is criticizing without a plausible alternative; Rust is at least more plausible of an alternative. But I also suspect that C+ASM will continue to rule the day here, especially now that these fuzzing techniques are become more widespread and industrial-strength.
  - pcwalton 13y ago
    Fuzzing has found plenty of security vulnerabilities, to be sure, but I'm skeptical that it makes static analysis obsolete. Even if it were possible to write a theoretical fuzzer that would find every possible security vulnerability, it'd still be a whole lot cheaper, and easier, to just have a tool that enforces that you write the code correctly in the first place than to spend time writing it in an unsafe language and then developing a world-class fuzzer to find all the vulnerabilities.
    - haberman 13y ago
      Totally agree that static analysis is better than fuzzing for preventing memory-safety vulnerabilities. If ffmpeg can be written in Rust without any disadvantages compared to C, then that's an easier way to ensure memory safety than fuzzing. I would be surprised if Rust can compete against C anytime soon for writing codecs, but will be pleasantly surprised if it can!
- pcwalton 13y ago
  > Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero. I'm not claiming it's production quality, but I did write an MP2 decoder in an early version of Rust: https://github.com/pcwalton/fempeg https://github.com/pcwalton/fempeg > Rust looks great for apps and middleware. I don't see ffmpeg or x264 (both of which are implemented with significant amounts of architecture-specific machine code -- an environment where neither C nor Rust is going to be able to help avoid the kind of bugs we're talking about) jumping ship any time this decade. I grepped through the commit log for bugs marked "j00ru", as suggested in the post, and the first 20 I found were all mostly-architecture-independent, straightforward C code (often bitstream parsing code). This is the kind of problem that Rust is generally good at securing and making performant. None of the 20 patches I looked at touched any assembly code at all.
  - ajross 13y ago
    My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly. But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say), not a HN post.
    - pcwalton 13y ago
      > My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly. I don't understand this. If you write in a safe language, the compiler rules out the memory safety bugs, regardless of the problem. > But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say), not a HN post. Of course, no argument there. I am reasonably confident that we can get there with tuning though, based on our benchmarks so far. :)
      - 13y ago
Nitramp 13y ago
Criticism is good if valid, and it is in this case.
yetanotherphd 13y ago
I don't think the poster was being snarkey, they were merely pointing out how hard it is to write correct C code. And there was no criticism of the developers, in fact the post implied that the bugs were the fault of C and not the developers.

gcr 13y ago

This list of criticism is copied verbatim from the article's list of fixed bugs, not composed directly by the OP.

scott_s 13y ago
The snark, however, is wholly original.
- npsimons 13y ago
  Considering it's entirely predictable and I've seen ones just like it a million times before, no, it's not. Relevant xkcd, esp. panel 2: https://xkcd.com/568/ https://xkcd.com/568/ "You will never find a programming language that frees you from the burden of clarifying your ideas."

ajross 13y ago

Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero. So perhaps the "some of these problems" is perhaps a bit spun. Rust looks great for apps and middleware. I don't see ffmpeg or x264 (both of which are implemented with significant amounts of architecture-specific machine code -- an environment where neither C nor Rust is going to be able to help avoid the kind of bugs we're talking about) jumping ship any time this decade.

haberman 13y ago
Yeah I don't think it's likely either. But it's a lot more likely than Modula-2, Ada, or any of the other languages that the OP would be arguing of in favor of C. OP is criticizing without a plausible alternative; Rust is at least more plausible of an alternative. But I also suspect that C+ASM will continue to rule the day here, especially now that these fuzzing techniques are become more widespread and industrial-strength.
- pcwalton 13y ago
  Fuzzing has found plenty of security vulnerabilities, to be sure, but I'm skeptical that it makes static analysis obsolete. Even if it were possible to write a theoretical fuzzer that would find every possible security vulnerability, it'd still be a whole lot cheaper, and easier, to just have a tool that enforces that you write the code correctly in the first place than to spend time writing it in an unsafe language and then developing a world-class fuzzer to find all the vulnerabilities.
  - haberman 13y ago
    Totally agree that static analysis is better than fuzzing for preventing memory-safety vulnerabilities. If ffmpeg can be written in Rust without any disadvantages compared to C, then that's an easier way to ensure memory safety than fuzzing. I would be surprised if Rust can compete against C anytime soon for writing codecs, but will be pleasantly surprised if it can!
pcwalton 13y ago
> Notably, and relevant to this post, the number of media codecs implemented is Rust is, I believe, zero. I'm not claiming it's production quality, but I did write an MP2 decoder in an early version of Rust: https://github.com/pcwalton/fempeg https://github.com/pcwalton/fempeg > Rust looks great for apps and middleware. I don't see ffmpeg or x264 (both of which are implemented with significant amounts of architecture-specific machine code -- an environment where neither C nor Rust is going to be able to help avoid the kind of bugs we're talking about) jumping ship any time this decade. I grepped through the commit log for bugs marked "j00ru", as suggested in the post, and the first 20 I found were all mostly-architecture-independent, straightforward C code (often bitstream parsing code). This is the kind of problem that Rust is generally good at securing and making performant. None of the 20 patches I looked at touched any assembly code at all.
- ajross 13y ago
  My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly. But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say), not a HN post.
  - pcwalton 13y ago
    > My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly. I don't understand this. If you write in a safe language, the compiler rules out the memory safety bugs, regardless of the problem. > But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say), not a HN post. Of course, no argument there. I am reasonably confident that we can get there with tuning though, based on our benchmarks so far. :)
    - 13y ago

Nitramp 13y ago

Criticism is good if valid, and it is in this case.

yetanotherphd 13y ago

I don't think the poster was being snarkey, they were merely pointing out how hard it is to write correct C code. And there was no criticism of the developers, in fact the post implied that the bugs were the fault of C and not the developers.