1 | ||
1 | ||
1 | ||
1 |
According the the StackOverflow developer surveys of 2023 and 2024 it went from earning on average $87,012 to $76,292.
Point is don't bother using Rust. It's true that companies value security. But most security flaws come from program logic and not the software's interaction with hardware. As systems get more concurrent logical race conditions are always possible. That's just the vector that actually matters to companies. Languages that help you manage concurrency with fewer errors are going to be valued over languages that let you access memory with fewer errors.
And less and less code is making direct memory access. Less C and C++ are being written every day. And besides that as software becomes concurrent and distributed and different parts of an application are proxied to each other through RabbitMQ the customer facing logic is even further separated from memory.
An attacker doesn't only need to deliver a payload that will overflow some server. He needs to deliver a payload that will convince a server to send a payload to another server to deliver a payload to another server to cause an overflow in some software that probably isn't doing direct memory access anyway (not C or C++).
The point is that companies will still care about reducing software to hardware security threats. But the Rust developers to do that already exist. The market is already saturated. That market is shrinking so it will stay saturated.
Whereas improving security in concurrency is a growing field.
Here is an example. Let's say a bank has an an authorization server to help people log in. Let's say for example 1 bank in 100 manages to program a bug that when there servers are really busy one in a thousand customers who log in end up logged in as each other when they log in at the same time. And they can do anything they want once in the account.
That really happened. What caused that? Logic errors. Would any amount of memory safety solve that problem? No. That is 90% of the errors companies are worried about. Rust will not make that problem secure because a human can always still work out the logic poorly.
If a programming language is difficult to work with and requires a lot of over thinking to get over and around its security model (which only cares about memory) then developers are going to be less flexible with adjusting a design when they have the thought that maybe just maybe the design could cause a problem. Rust code has more technical debt the second it's written. It becomes calcified by extra code immediately by problem solving how to use the language because it's so restrictive. This creates balls of code that no one wants to pick apart and rework. That's why it's largely only useful for rewriting existing code whose model is already established. If coding fresh, the extra considerations designing around the language instead of to the problem would likely introduce more vulnerabilities than most other code.
Either way. Don't bother with it. Let the commie shit-stains that bought the Rust-propaganda go down with their sinking ship.