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.

> 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

> 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.

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.

> 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. :)

> I don't understand this. If you write in a safe language, the compiler rules out the memory safety bugs, regardless of the problem.

For performance sensitive code, you sometimes need to deliberately step out of the strongholds of the compiler.

Rust allows this via `unsafe` blocks, which essentially have C semantics (and allow the use of inline assembly too).

> For performance sensitive code, you sometimes need to deliberately step out of the strongholds of the compiler.

...or just add more primitives to the language.

Why make the language larger when you can write identical things in libraries? (For Rust, you can use `unsafe` blocks to write very low-level primitives in normal user code and then expose a safe interface above them.)

It depends on what you guys are talking about.

If you mean "constant" primitives, i.e. things which don't require to expand the language grammar or type system, then it's a question of future prevalence of usage of said primitives. If they become almost ubiquitous to any project, then they obviously need to be included in the standard libs. If you're talking about a new language feature, that depends on how much that new feature may help design and write future libraries, and also what are the aims of said language. I understand that rust aims to become a safer system language, so any feature helping the design of low level, performance critical code should be welcome.

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.

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.

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!

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

The snark, however, is wholly original.

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/

"You will never find a programming language that frees you from the burden of clarifying your ideas."

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

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.