earlier statements from Microsoft
Later statements from Microsoft will announce a new language, R#, which is more or less the same thing as Rust but which requires the .NET runtime.
A new patch was this week submitted to the Linux Kernel mailing list, progressing the Rust for Linux Kernel project. Rust for the Linux kernel is a project sponsored by Google but with wide industry support Rust for the Linux kernel is a project sponsored by Google but with wide industry support The new patch will "add …
or is Rust just trying too hard - it wants to join the party it's knocking on the door and nobody's answering.
From what I see, the biggest issue with Rust is the evangelical zeal of its proponents/proselytisers. It's a solution looking for a problem and they are trying to push it everywhere. Unfortunately when you try pushing and over hyping stuff, people just turn off and reject your advances. I'd far rather see a language just creep up on us and discover it was brilliant for a particular task and be adopted than be lectured to by a bunch of wannabes trying to be the next big thing because they've nailed themselves to the floor and they want you to do the same.
Yes, you probably can't compile something that's not safe but you can still compile flawed logic and no amount of language design is going to cater for developers (and we're all capable of it - no matter how good we are) getting the logic wrong so Rust really doesn't add a lot.
Rust is not trying too hard. Rust was designed to be a systems-level language that addresses well-known weaknesses in other languages. You can read widely available resources on the whole breadth of Rust design goals, but the primary one everyone talks about is memory safety. Operating systems have been battling memory access issues forever; Windows is coming up on 40 years old, and still struggles with hacks achieved through buffer overflows, etc. So, if you could eliminate this entire category of vulnerabilities by the design of the programming language itself, that would be huge.
You are correct that you can't correct program logic errors in a programming language. But Rust helps address other major problems like the memory safety issue.
1.) Nobody forces you to use Rust.
2.) Cyber Security (more precisely: a lack of) is a very real problem. Memory safe languages are an important security measure. See presentation
3.) As stated in the presentation above "Other measures such as proper scanners, parsers and strict input validation are still required"
[quote]Cyber Security (more precisely: a lack of) is a very real problem.[/quote]
True, which most of it is due to system misconfiguration, foolish or credulous trust phishing), poor security layer (few lines of iptables as firewall, default profiles appamor restricting nothing instead of allowing only what needed, password reuses... ) or using web based configuration tool and/or opening it to the net...
I mean, saying that implementing rust will reduce security incident is gag...
You are saying we can forget the high-grade security risks because there are plenty of incompetent people around ?
On page 3 of this you can find why this is a very weak argument. The weapons-grade actors will use exactly such weaknesses to flatten entire corporations, complete with dedicated, full time IT security staff.
MTAs, Email programs, EDI systems, web servers, TCP/IP stacks - they are exposed to ALL bad guys of the planet. As soon as they have a foot inside your intranet, all the funny service ports of your PCs (of services mostly running inside the kernel) will be exposed too. And all the half baked database listener processes.
You're right it doesn't protect you from application level bugs, but it *will* protect you from pointer/reference exceptions, data races, double frees, buffer under/over flows. The sort of things that can crash or compromise software.
Even the most experienced, specialised, & scrutinized C & C++ programmers in the world are victim of these issues, so what does that say of the trillions of lines of code written by other programmers?
So that's the problem Rust is there to solve and why it has garnered so much interest from the likes of Google, Amazon, Microsoft and others. It's not hype either, it's proven technology.
C++ will protect you from those things, too. You just have to bother to use it. In fact, if the criterion for being supported in the kernel is that you need to be C-compatible and offer a degree of safety beyond what C can manage on its own, it's rather odd that Rust has been chosen as the first such "additional" language.
C++ Compilers have no support for memory safety built-in. All you can do is to try to be a disciplined user of smart pointers, index checked arrays and static checker tools. There is no coherent idea of memory safety built into C++, and Mr Stroustrup apparently considers this not a priority. He says it would be an all-or-nothing change and would break old code, so he does not want to tackle the issue.
Of course that is not the exact truth - one could think of a Compiler command line switch and some sort of "unsafe" keyword to gradually bring this into the C++ standard. And to gradually transform an existing C++ system into a memory safe system.
And a Rust compiler won't stop you assigning values to the wrong variable. So what? No language is going to completely absolve you of the need to get things right. Both C++ and Rust are capable of expressing unsafe code, but it's clear in the source if you do and it is not the default for anyone competent in either language.
When you say "disciplined use" you make it sound like it is hard. It isn't. You use smart pointers to hold resources. If you see a dumb pointer holding a resource, you know it is a bug.
Has anyone seen Rust used for a project where functional safety is a consideration?
All of the functional safety standards I have been involved with require the use of a standardised programming language, which means it will not be easy to use where functional safety is a consideration (which would be a pity).
The optimizing C compilers used in automotive, medical, aerospace and rail are being "qualified" for use by large test code batteries and essentially "old age" and "widespread use with small problems".
There have been cases of compiler and MCU bugs, because the approach above is NOT mathematical correctness proof.
The same can soon be said about the Rust compiler.
Also, functional safety requires very extensive test efforts including unit tests for each subroutine, which would most likely expose compiler bugs.
In the end, there is no absolute safety, but only a "best effort, according to state of the art".
Biting the hand that feeds IT © 1998–2022