Because believe it or not Twitter is still popular despite everything
wkk
You say that as if machines don't get dirty and still require a good amount of hygiene/cleaning to keep up
Don't get me wrong though because I am also in favor of automation only because I believe it will make some parts of work more bearable, minus the job displacement problem caused by our current economic model...
Just fork it 🤓
It definitely feels like a knee jerk reaction, but there would be some merit to it: The Rust language feels apt to implement a kernel with. If I remember correctly that's what Redox is trying to accomplish? https://redox-os.org/
Some places are like that
Antagonizing the borrow checker is wrong. If it screams it does so to prevent you from writing a mistake. Eventually once you have enough experience you should write code in such a way that doesn't trip the borrow checker because you know how to properly handle your references.
Is it difficult to learn at first? Yes, but the benefits of learning this outweighs the downsides such as writing code that may use references when it shouldn't.
I'm not a Rust aficionado, but the few Rust I've written opened my eyes on issues that I have been dealing with in other languages but for which I was blind.
Lastly I tried following a Godot project tutorial that was using GDScript except I challenged myself to follow it but rewrite the examples given using Rust's bindings for Godot. It was definitely more cumbersome to work with, but I might also have been doing something wrong (such as blindly transcribing GDscript instead of writing more idiomatic Rust).
All of that to say 1) borrow checker is your friend and 2) scripting languages will always be more convenient at the cost of being way more dirty (way less safeties)
In the end you need to pick the right tool for the job. Multiple tools may be used within the same project.
If you can avoid running batch files altogether then great, amazing. But there are projects out there using Rust that still depend on running those and that's the focus of the issue... But yeah I cannot wait until the day I won't hear about cmd.exe again.
To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.
Because a batch file (.bat or .cmd) is basically a set of cmd.exe instructions I guess that's why you can't get away from it.
And as if making sense of this CreateProcessA
system call wasn't funny enough, you also need to figure out how to safely prepare that lpCommandLine
for it following all of cmd.exe's weird escaping rules... lol
It's definitely not Rust's fault, but it's kinda Windows' one and cmd.exe escape logic... It's really difficult to write logic that will correctly escape any argument given to it, cmd.exe really is a pain to deal with :/
The Rust security team faced a significant challenge when dealing with cmd.exe's complexity since they couldn't find a solution that would correctly escape arguments in all cases.
As a result, they had to improve the robustness of the escaping code and modify the Command API. If the Command API cannot safely escape an argument while spawning the process, it returns an InvalidInput error.
"If you implement the escaping yourself or only handle trusted inputs, on Windows you can also use the CommandExt::raw_arg method to bypass the standard library's escaping logic," the Rust Security Response WG added.
I get that in situations where they can't safely escape a parameter they'll just stop with an error, which sound as sane as one could go with this!
I wouldn't call that "messy and inefficient" but you do you. I'd be curious to know what's a "clean and efficient" solution for you when it comes to routing packets around the planet :)
It's like you're sucking the fun out of us... Wait a minute
Python with PyPI, C# with Nuget, Docker with Dockerhub, Java with Maven Central, hell even just regular Linux packages from dodgy repositories...
Supply chain attacks concern almost everything everyone everywhere.