It's not that simple to do a bounty program, my uninformed guess is that they are almost definitely targeting a number of jurisdictions whose laws are familiar with and/or they have some kind of representive in

It says nothing about "asian people". Verbatim quote, in full:

> The contest is open to individuals or teams of individuals who are legal residents or citizens of the United States, United Kingdom, European Union, Canada, New Zealand, or Australia.

Probably legal and possibly political reasons that comes with the source of money.

As a resident of Japan, I thought the exact same thing. (I'm also a citizen of an EU country, which would permit me to participate, but most of my colleagues couldn't.)

Actually, I'm more shocked that somehow Québec residents are eligible. Knowing how contest rules work, Québec is usually excluded because of its onerous rules. For one, the rules are not (also) written in French - which is a requirement for contests.

> Based on the article, it seems that with highly complex logic, safety does come at the cost of raw performance, and it can be very hard to compensate (withing the safety requirements).

In Rust. These are Rust issues, not issues with safety in general.

The issue with bound checks for exemple is entirely avoidable if you prove that all your calls are within bounds before compiling, same thing for partial initialization.

The core issue is that the strategies Rust adopts to ensure memory safety are neither a panacea nor necessarily the right solution in every case. That being said, I think it's a very nice idea to try to write a decoder in Rust and have a bounty for optimization. Rust is popular so work on producing fast and safe Rust is good.

This would be utterly fantastic.

The sort of bounty + interview question I would ask when I'm really looking for those who will actually use such optimal algorithms in practice where it directly applies.

Which is exactly this for video decoders.

In fact, a bounty will show us who really is serious or not and even some interviewers don't have a clue why they ask for 'optimal algorithms' in the first place. Maybe just to show off that they Googled or used ChatGPT for the answer before the interview.

Well, you can't do it for this one. The one who improves this and can explain their changes will have a impressive show of expertise which puts lots of so-called 'SWEs' to shame.

> This pays for at most a week of work.

Does that mean that rust devs earn 60k monthly minimum?

Is this yet another "every developer on the globe makes around the same as I do" post?

Man, I’d have gotten into Rust earlier if I knew the salaries were a minimum of $960,000

> This pays for at most a week of work

What kind of lunatic would pay that kind of money for a dev for a single week

What are you talking about? 25~30k is almost a year's salaries for a dev in Eastern Europe/South America.

I think latency sensitive applications will usually prefer better performance and deal with safety issues, as opposed to better safety and deal with performance issues.

So I doubt it's any religious thing between c and Rust.

I may be wrong but if you're one of the "big guys" doing video then a 5% performance difference probably translates into millions of $ in the CPU/GPU bill

Developers fight tooth and nail to get every bit of performance from video codecs because this goes directly to battery life and heat on a scale of billions of devices. You can't handwave a 5% performance drop as if this is some recipe app. People pour over microamp power analyzers and high resolution thermographs because they "really care."

I can think of a few use cases:

1. Desktop - If both implementations run the same but one is faster, you run the faster one to stop the decode spluttering on those borderline cases.

2. Embedded - Where resources are limited, you still go for the faster one, even if it might one day leas to a zero day because you've weighed up the risk and reducing the BOM is an instant win and trying to factor in some unknown code element isn't.

3. Server - You accept media from unknown sources, so you are sandboxed anyway. Losing 5% of computing resources adds up to big $ over a year and at enough scale. At Youtube for example it could be millions of dollars a year of compute doing a decode and then re-encode.

Some other resistances:

1. Energy - If you have software being used in many places over the world, that cost saving is significant in terms of energy usage.

2. Already used - If the C implementation is working without issue, there would be high resistance to spend engineering time to put a slower implementation in.

3. Already C/C++ - If you already have a codebase using the same language, why would you now include Rust into your codebase?

4. Bindings - Commonly used libraries use the C version and are slow to change. The default may remain the C version in the likes of ffmpeg.

> I'm really surprised that a 5% performance degradation would lead people to choose C over Rust

I'm really surprised that because something is in Rust and not in C, it would lead people to ignore a 5% performance degradation.

Seriously... when you get something that's 5% faster especially in the video codec space, why would you dismiss it just because it's not in your favorite language... That does sound like a silly reason to dismiss a faster implementation.

> especially for something like a video codec

Why especially video decoders?

> I wonder if they really care or if this is one of those "we don't want to use Rust because of silly reasons and here's are reasonable-sounding but actually irrelevant technical justification"...

I would have thought video decoders are specifically one of the few cases where performance really is important enough to trump language guaranteed security. They're widely deployed, and need to work in a variety of environments; everything from low power mobile devices to high-throughput cloud infrastructure. They also need to be low latency for live broadcast/streaming.

That's not to say security isn't a concern. It absolutely is, especially given the wide variety of deployment targets. However, video decoders aren't something that necessarily need to continually evolve over time. If you prioritize secure coding practices and pair that with some formal/static analysis, then you ought to be able to squeeze out more performance than Rust. For example, Rust may be inserting bounds checks on repeated access — where as a C program could potentially validate this sort of information just the once up front and pass the "pre-validated" data structure around (maybe even across threads) "knowing" that it's valid data. Yes, there's a security risk involved, but it may be worth it.

I assume they're hoping to nerd snipe someone

Can’t talk about the other countries but $20K is a shitload of money in many countries of the EU.