I believe it goes something like, "I have constructed a strawman that Rust claims that all code written in it is automatically safe by all conceivable definitions of safe, but look, ha ha, here's something that detects unsafe code in Rust!", and I don't mean "code marked in unsafe blocks".
It's a concatenation of several logical fallacies in a row; equivocation, straw manning, binary thinking about safety, several others. It's hard to pick the main one, but I'd go with the dominant problem being a serious case of binary thinking about what "safety" is. Of course, if the commentor is using anything other than Idris for all their programming, they're probably not actually acting on their own accusations.
> Of course, if the commentor is using anything other than Idris
I'm sure the Idris compiler has bugs somewhere too. If the OP actually programs, they are violating their rationale (I'm quite sure assembly or assembled binary aren't ok either).
Just to find agreement about the terminology, wouldn't we call all code that is not inside an unsafe block "safe?" If so, then adding "generally" is superfluous, right?
If not, then how is "generally safe" different from "not inside an unsafe block?"
I didn't expect you to outright confirm that you are using the "solve all programming problems ever" strawman, but, err, thanks for the proof I guess. I thought maybe I went a bit overboard in the reading between the lines but I guess I nailed it.
They are claiming that because code in ‘unsafe’ blocks in Rust can have undefined behavior, that the language is no safer than C.
This does not settle the debate because unsafe is rarely needed for a typical Rust program. In addition, the presence of an unsafe block also alerts the reader that the set of possible errors is greatly increased for that part of the code and more careful auditing is needed.
It’s a little like saying traffic lights are useless because emergency responders need to drive through them sometimes, so we should just leave intersections completely unsignaled and expect drivers to do better.
Rust is by default restrictive and requires you to explicitly make it unsafe, C/++ are by default unsafe and require you to explicitly make them restrictive.
It is a tool for checking that your unsafe code doesn't cause UB. It doesn't really settle anything, but the commenter uses it as a gotcha to say "rust is no better than C, because you still can compile code that contains UB".
Well, the general 'Rewrite All in Rust' consensus is that it solves all general programming problems, ever.
Yet, the linked repository shows a huge list of cases in which simple, documented use of Rust can cause Undefined Behavior (a.k.a. 'UB')
Pretty much every argument of Rust advocates against C/C++ boils down to either 'but memory safety' or 'but UB'.
Yet there are many convincing counter-arguments that boil down to 'but CompCert' or similar, and, as the linked repository shows, there might be at least some truth in there?
No serious person claims that Rust solves every problem ever.
Also, many people cite things like Cargo as a reason to prefer Rust over C and C++, as well as other things. UB is a big part of it, of course, but it isn’t the only thing.
I selected it for performance reasons myself, the UB protection was a nice benefit that was expected, cargo wasn't expected and is extremely nice coming from the cmake,conan,vcpkg and duct tape world I came from.
You're available as an expert witness to that fact?
Because, eh, well, in at least one of the Rust-related situations that I'm involved in right now, someone might soon very well require the services of a person both as wise and reluctant-to-offer-any-kind-of-compromise as yourself...
The situation you've alluded to in another thread seems to involve an unsafe block (since it's using a type which is only usable in an unsafe block).
Let me be even more explicit than steveklabnik here. If your code, including any libraries you link to, is 100% Rust and free of any unsafe blocks, then (barring compiler bugs) it is impossible to execute undefined behavior. If your code has an unsafe block, then it is possible execute undefined behavior. Note that it is possible for safe code to execute undefined behavior, IF there was an unsafe block that did an operation that requires the programmer to promise something was true that was not true.
For example, there is an unsafe method that will let you convert a pointer to a reference with an arbitrary lifetime. If you wrap that in a safe function, you can return a reference to an object whose lifetime has ended, and cause undefined behavior in attempting to use that lifetime--the attempt can even be outside the safe block. But were that unsafe block that upgraded the lifetime not present, then you couldn't cause the later undefined behavior to happen.
In short, an unsafe block is where the compiler can no longer guarantee that the conditions that prevent the ability to observe undefined behavior are present, and it is up to the programmer to ensure that these conditions are met, and even and especially ensure that they continue to be met after the unsafe block completes. I do worry that too many programmers are blasé about the last bit, and it sounds like your coworker may fall into that category. But Rust has always maintained this principle.
OK, you truly seem not to understand how much damage you're dealing to the general population using absolutist statements like this, do you? Nor do you seem to understand "compromise", like at all, because you seem to equate it with "tit for that", which is unsurprising, but still... disappointing.
In any case, I'm truly done here, in all senses of the word, but I still I wish you and your acolytes the absolute best.
What are you talking about? Yes it's impossible to have UB in safe rust unless theres some obscure compiler bug or something. This isn't a controversial statement.
> Well, the general 'Rewrite All in Rust' consensus is that it solves all general programming problems, ever.
a) There is no such consensus. The actual consensus is that even if Rust solved all problems, it would not be financially feasible to rewrite pretty much any substantial project.
b) While Rust does solve many problems, it is nowhere close to solving all safety, otherwise there would be no `unsafe` keyword. Alas, fully proving safety in an impure, turing-complete language is mathematically impossible.
c) The only reason you would think that there's some sort of woke Rust lobby, is if you spend way too much time subjecting yourself to opinions of literal sixteen year olds on twitter.
Towards general mental health. I'm just a C# wage slave, and I'll admit, when being prompted, that my language, its vendor, its runtime environment, and its general approach are, to put it kindly, flawed.
However, as evidenced by the arguments and voting in this thread, Rust proponents will take no criticism, whatsoever.
I linked to a GitHub repository that documents many, many instances in which generally safe Rust causes UB.
The same kind of UB that recently hit one of my coworkers, caused a 3-day outage and now (despite all my counseling to the contrary!) will burn them out permanently.
My only request: can you guys please back off just a little bit? Programming is already hard enough without the purity wars you're stoking all the time...
to be fair, from his perspective, it's often the rusty crowd who is stoking the flame wars - this sounds like a reaction to them.
how often do we hear something like "C and C++ are horribly flawed and completely unsafe. it's basically a crime against humankind and gross negligence to use them"?
i get weary of that kind of thing too. i wouldn't approach it by reacting in the same way as the GP comment, but i get it. and it's not really that much of a strawman. it's more exasperation and sarcasm.
personally, i'm very interested in rust. but everytime someone at best "overhypes" it or at worse, outright dogs on other languages, it's a negative point toward dealing with the whole rust ecosystem.
In all honesty, I don't see that sort of thing posted except maybe the overly naive excited "omg I love rust" post in /r/rust from someone just learning it which no one should be taking as credible.
I do, however, see people trot out the oft-repeated "rust evangelists want to rewrite everything in rust" or "rust people say programming C++ is a crime against humanity", but it seems to me that's the only place I see this argument. In other words, it's a simple strawman.
People can, in the most neutral way possible, point out facts about how safe or unsafe Rust is compared to C and C++. People will STILL complain about how the Rust zealots are bullying their language. This is how it plays out every time.
You can look at this thread. The “exasperation and sarcasm“ is stupid and one-sided. “But” they always say “that’s just a reaction to a previous debate”–because the Rust zealots are always in the rear-view mirror, never in front of them.
How about complaining about something in Rust… that is bad? Like how un-ergonomic Async is? Or how pointy and awkward the syntax can be? Instead they choose to fight the losing battle over how C and Rust are equally unsafe or how actually Rust’s safety doesn’t matter, depending on the phase of the moon. Then they whine about tone and zealotry when they realize arguing against Rust safety from the C and C++ side is a losing battle and they have run out of arguments.
Each wants to claim a keyboard and a mouse, but due to new pair programming requirements set by management there is one fewer set of peripherals than there are developers.
Not a bad thing at all… but this is the same mental model provided by the so-called atom-based state management systems in React. I believe Jotai is the most popular.
Not OP but I too have built this, basically a few hundred lines of python to implement something like json rpc (plus introspection to answer help requests / publish typed api info) on top of AWS lambda.
https://station-keeper.cubicle6.com/