“Land initial Rust MP4 parser and unit tests”

Re:“Land initial Rust MP4 parser and unit tests” by pcwalton on Thursday June 18, 2015 @03:39PM (#9741129)

A more modern language (modules, closures, pattern matching, package management, type inference) and memory safety are nice. If I were writing a new codec, I'd seriously consider writing the lion's share of it in Rust, to save time and to avoid security problems.

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by Alupis on Thursday June 18, 2015 @03:56PM (#9741221)

I think the sentiment of the parent was that we should avoid (re)writing things in pet language of the week.

Sure, Rust has a great following, but so does GO. Which is the "right" choice for a new codec? I don't think there is a clear answer.

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by geofft on Thursday June 18, 2015 @04:15PM (#9741354)

Rust does not require a runtime / garbage collector and offers a programming model that interacts very precisely with external threading requirements. It supports being called from the native platform ABI without initialization, and it supports writing libraries to match an existing, native ("C") ABI and function as a drop-in replacement. Go does not do these things.

The suggestion to use Rust here is because this is specifically a thing Rust was designed to do, not because it has a huge following. Go is a great language, but it is designed for different things (and has a following of people who want it to do those different things). If those two languages are the two choices for replacing a codec that functions as a library, there is an objectively correct answer.

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by Rusky on Thursday June 18, 2015 @04:11PM (#9741330)

For a codec there is probably a clearer answer than for some other applications- codecs are very performance-sensitive (probably don't want a GC) and also very security-sensitive (you're decoding completely untrusted data). Previously they've always been written in C or C++ because of the performance requirements, and Rust keeps the same performance while adding some more safety checks. Go doesn't.

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by coldtea on Thursday June 18, 2015 @04:53PM (#9741550)

>Sure, Rust has a great following, but so does GO. Which is the "right" choice for a new codec? I don't think there is a clear answer.

Sure there is. Go would be an absolutely horrible choice for writing a video codec -- and wasn't even designed for that kind of work in the first place.

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by bsder on Thursday June 18, 2015 @08:53PM (#9742494)

> Sure, Rust has a great following, but so does GO. Which is the "right" choice for a new codec? I don't think there is a clear answer.

Actually, there is quite a clear right answer for a hardware codec.

You have 3 choices: C, C++, or Rust.

While C or C++ probably is better for the core of the codec, that's not where your security and concurrency issues probably are.

Most of your issues are in unpacking headers, validating packets, getting decode parameters correct, etc. Rust is WAY better for this task than C/C++ from a security or concurrency point of view.

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by pjmlp on Friday June 19, 2015 @02:41AM (#9743319)

There is also Ada. :)

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by pjc50 on Friday June 19, 2015 @05:39AM (#9743770)

How easy is it to inter-link C and ADA?

[ Parent | on HN ]

Re:“Land initial Rust MP4 parser and unit tests” by pjmlp on Friday June 19, 2015 @06:07AM (#9743845)

Like this with GNAT

https://gcc.gnu.org/onlinedocs/gnat_ugn/Interfacing-to-C.htm...

[ Parent | on HN ]