Rust-Written Stateless Codec Drivers Make A Lot Of Sense

[alphabitserial]

The expressive typing that Rust provides seems like a great fit for this kind of highly structured data. Seems like having a virtual driver with more easily verifiable correctness to compare against would be of value to existing drivers and make implementation of future drivers easier as well. Sounds like a great idea; nice work from Daniel Almeida!

[piotrj3]

Because you can assume bounds sizes for a codec stream at compile time? No, you can't. None of your mentioned solutions can avoid unsafe access if you want performance.



I covered the unsafe (get_unchecked_mut) aspect in my post. Unsafe means you are achieving nothing but wasting time writing support code just to use Rust. In short, you are just writing janky C++ using a Rust compiler.

But hey, if that's what you want to do (or rather talk about), I will leave you to it. I'm gonna limit my Rust posts to once a week because verbosity and noise is one area where Rust developers have anyone beaten and I don't personally have the time to reciprocate.

1st. Iterator loops can be checked compile time. Regardless of size.
2nd. Fixed size buffers with fixed iterations up to max buffer size won't produce runtime checks. That is really common in codecs/performance sensitive things, as fixed size buffers are vectorized really well.
3rd. If you add classic C style security check (what is must have in codecs to prevent exploitation), Rust will not insert own bounds check.

[TheMightyBuzzard]

And where is the fun in that? Is it not better to discuss a topic I do not dominate with people who, in my opinion, knows less about the subject? If we all should act like adults, we might end up with a consensus and learn something. What an aweful idea.

Consensus does not mean, imply, nor even hint at correctness.

[stormcrow]

Consensus does not mean, imply, nor even hint at correctness.

Nor does correctness imply there's only one correct solution, or that a correct(*) solution is the optimum solution's path. It also doesn't follow that unsafe Rust is just as bad (security wise) as code for the same purpose in C (or vice versa). People conveniently forget (i'm likely being more generous than I should) about IB, UB, logic analysis, and formal methods. It's more difficult to shoot yourself in the foot in Rust, but not impossible. Conversely, it's extremely easy to shoot yourself in the foot with either C or C++ and takes a lot more effort to not do so. However, writing things in safe Rust doesn't necessarily imply slow. Likewise, not everything written in C is actually fast. But neither language will stop you from making incorrect assumptions or screwing up a program's logic flow. Or, as in one very high profile disaster, mixing up Imperial and Metric units even though the program was written in the otherwise very safe language, Ada. Logic does not dictate one should pick an unsafe tool when the safe one will do the job just because humans make mistakes neither tool can address, rather the opposite.

*) Correct is defined as a solution that's deterministically bug free, but may or may not be fully optimized for the hardware or every possible input. Many languages often have more than one correct approach to solving a given problem, but they may not all have equal performance especially when run on real hardware and built with real tools.

[bug77]

1st. Iterator loops can be checked compile time. Regardless of size.
2nd. Fixed size buffers with fixed iterations up to max buffer size won't produce runtime checks. That is really common in codecs/performance sensitive things, as fixed size buffers are vectorized really well.
3rd. If you add classic C style security check (what is must have in codecs to prevent exploitation), Rust will not insert own bounds check.

But, but, but... Rust kills kittens?

[vextium]

Because you can assume bounds sizes for a codec stream at compile time? No, you can't. None of your mentioned solutions can avoid unsafe access if you want performance.



I covered the unsafe (get_unchecked_mut) aspect in my post. Unsafe means you are achieving nothing but wasting time writing support code just to use Rust. In short, you are just writing janky C++ using a Rust compiler.

But hey, if that's what you want to do (or rather talk about), I will leave you to it. I'm gonna limit my Rust posts to once a week because verbosity and noise is one area where Rust developers have anyone beaten and I don't personally have the time to reciprocate.

I hope you know you're talking to one of the head engineers at System76 LMAO

[kpedersen]

I hope you know you're talking to one of the head engineers at System76 LMAO

Aren't many of us here lead engineers in various tech companies? Middle aged men squabbling about programming languages on a Linux forum *probably* means they do this as part of their career haha.

Now I am curious and feel perhaps we should do a poll.

That said, when "head engineers" of Sun were preaching about Java being the "C++ killer" or when Microsoft "head engineers" stated that C# was the future, I was also very much in disagreement as I am now. Once you put aside that slightly childish celebrity infatuation mentality, you will realise that any engineer can make disagreeable judgements based on hype. That is what discussion is for.

[alphabitserial]

Aren't many of us here lead engineers in various tech companies? Middle aged men squabbling about programming languages on a Linux forum *probably* means they do this as part of their career haha.

Now I am curious and feel perhaps we should do a poll.

That said, when "head engineers" of Sun were preaching about Java being the "C++ killer" or when Microsoft "head engineers" stated that C# was the future, I was also very much in disagreement as I am now. Once you put aside that slightly childish celebrity infatuation mentality, you will realise that any engineer can make disagreeable judgements based on hype. That is what discussion is for.

Pretty funny to see your views on the open-source community are about as narrow as your views on engineering. Some of us aren't middle-aged, men, or primarily on here to argue. 😂

[Sonadow]

That said, when "head engineers" of Sun were preaching about Java being the "C++ killer" or when Microsoft "head engineers" stated that C# was the future, I was also very much in disagreement as I am now. Once you put aside that slightly childish celebrity infatuation mentality, you will realise that any engineer can make disagreeable judgements based on hype. That is what discussion is for.

Except that C# became the single biggest, if not second-biggest go-to language for Windows software development and validating Microsoft's head engineers' claims.

And Java still remains a lot more favored over C++ today.

[mmstick]

Aren't many of us here lead engineers in various tech companies? Middle aged men squabbling about programming languages on a Linux forum *probably* means they do this as part of their career haha.

My career has been developing with Rust since 2015. There are no squabbles about what language we use. If you develop a new project, do it in Rust. No one wants to use C or C++

For the time that I was working on pop-shell, I adapted Typescript for use with GJS. All of us here like languages with type systems.