Linux's V4L2 VP9 Codec Kernel Code Rewritten In Rust For Better Memory Safety

[uid313]

What's so amazing? Rust is far from maturity of C and code written in Rust is much harder to read and follow IMO. I'm waiting for large project written in Rust to see if it's really capable of replacing C. So far there are only tiny projects which are doing simple tasks. I'd love to see PostgreSQL equivalent. It's so much hype and promises about Rust, but nothing interesting to see so far. The order should be different.

I think Rust is easier to follow than C.

In C when I look at a function signature I have no idea if the return value or any of its arguments can be null, while in Rust it is apparent from the Option type.

In C a function might return the value -1, if it does that is quite surprising and unexpected, furthermore I don't really know what it means even though I can guess it is some kind of error. In Rust this will never be a surprise as a function will return the Result<T, E> type which tells me there can be an error and gives me an enum to figure out what the problem is.

In Rust the loop will be a simple foreach loop, but in C the index can start on 0 or 1 or something else, and it can be i++, i--, ++i, or --i or something else confusing.

[BreachScrambler]

https://github.com/qdrant/qdrant

Ugh I remember fixing the write ahead logging in that project. Huge swath of the WAL was treating a memory mapped folder as a file. "Everything is a file" only applies to Unix and completely breaks things when applied to Windows. Good luck diagnosing that kind of error in C.

[Volta]

"only small projects" https://github.com/uutils/coreutils

I'm talking about database and you're showing me this? Show me a big project where scalability and memory management have huge impact on performance.

[Volta]

Kernel getting provable safety features of course.

Maybe partially. It's not Rust in user space and Linus explained why kernel is different.

And I'm always far from the maturity that my parents have (at least until they die). Was this supposed to be an argument?

The argument is about ecosystems. C has at least two great and mature compilers and it's very stable language. Rust code written last year may be obsolete now. Rust is gaining a lot more features every year. Dozens of crates, abstractions make it hard to audit - personal opinion.

What? Harder to read and follow than C? I see, only in your opinion, that might very well be. Because for the typical programmer that would be the other way around.

Even if you never heard about rust as C programmer, you could very easily understand rust code. Writing of course is a different beast.

It seems it's not so obvious:

https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html

Of those respondents who shared their main worries for the future of Rust (9,374), the majority were concerned about Rust becoming too complex at 43% — a 5pp increase from 2022.

Its complexity is still growing.

[pabloski]

C has at least two great and mature compilers and it's very stable language.

Yeah so stable that undefined behaviours and an incomplete programming model are there after 50 years

Rust code written last year may be obsolete now.

No because (1) deprecation is a slow process, (2) Rust can mix and match code written for various versions of the language, (3) the latest and greatest compiler is forced to implement the old and even deprecated bits. It is the only language where you can take a crate unmantained since forever and use in your newly written code!!

[kloczek]

You're going to be waiting a very, very long time. Even if there were, one vulnerability per million lines of code is better than one vulnerability per thousand lines of code.

https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust

[mmstick]

The argument is about ecosystems. C has at least two great and mature compilers and it's very stable language. Rust code written last year may be obsolete now. Rust is gaining a lot more features every year. Dozens of crates, abstractions make it hard to audit - personal opinion.

The official Rust compiler frontend is supported by three compilers today. LLVM, GCC, and Cranelift.
Additionally, Rust now has a fully qualified compiler which supports Rust 1.68, which is named Ferrocene:

Ferrocene is an open source qualified Rust compiler toolchain. With this, Ferrous Systems invested its decade of Rust experience to make Rust a first-class language for mission-critical and functional safety systems.

For its first release, Ferrocene 23.06 is a ISO 26262 (ASIL D) and IEC 61508 (SIL 4) qualified version of the existing open-source compiler, rustc, based on Rust 1.68.

I'm talking about database and you're showing me this?

You still haven't responded to SurrealDB. There's also SpacetimeDB, and a myriad of other options.

Show me a big project where scalability and memory management have huge impact on performance.

• https://discord.com/blog/why-discord...rom-go-to-rust
• https://discord.com/blog/using-rust-...ncurrent-users
• https://www.figma.com/blog/rust-in-production-at-figma/
• https://dropbox.tech/infrastructure/...ur-sync-engine

Even Cloudflare uses Rust extensively. If it wasn't scalable, do you really think they'd be using it?

https://github.com/cloudflare/pingora

Pingora is battle tested as it has been serving more than 40 million Internet requests per second for more than a few years.

[mmstick]

https://stackoverflow.com/questions/...y-leak-in-rust

Leaking memory is usually intentional. It is not the same thing as a memory safety violation. Leaking memory is perfectly safe, and the standard library provides methods for doing it.

[mdedetrich]

Rust code written last year may be obsolete now..

Stop spreading misinformation, Rust has entered stability versioning ages ago which guarantees that non-nightly stable code will continue to compile for the forseable future

[mdedetrich]

I'm patiently waiting for first memory leak or memory corruption in that rust code ..

Rust's linear type system which is how it tracks memory access has been formally verified so you may be waiting for a while. That said, there may be issues in the backends (i.e. llvm/gcc) but that isn't Rust's fault and C is in the exact same boat in that regard.

Fun fact, as Rust has been developed over time it has actually revealed many bugs within LLVM especially when it comes to aliasing.