If you drive a car, have you read the entire owner's manual for every car you've owned? If you're a homeowner, how about your hvac system? What about your system shell? Your compiler(s)?
At some point you need your tools to be intuitive enough that you don't need to read an entire manual in order to do your work.
It's neither arbitrary nor magic; it's math. And unsafe doesn't disable the type system, it just lets you dereference raw pointers.
This headline is based on responses to the question "what are your biggest worries about the future of Rust", not "are you worried about the future of Rust." So of course most of the respondents answered with a concern about the language.
Do you take this sentence seriously, or not?
I will do everything I can do to stop this.
As far as I can tell, "this" here refers to literally any Rust code that isn't constrained within a specific driver. That does indeed seem like a full-on attempt to stop the R4L project entirely.
He does appear to have a real technical concern regarding maintainability.
"Appear" is doing some heavy lifting there. Opponents of the R4L project always couch their objections in technical concerns. For what it's worth, I can't actually find any concerns of merit or substance in that particular thread, although navigating mailing list threads is honestly pretty error-prone, so I may have missed it.
It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.
[warning: "annoying Rust guy" comment incoming]
I don't think Rust is perfect, but arguably I do "idolize" it, because I genuinely think it's notably better both in design and in practice than every other language I've used. This includes:
In a literal sense, I agree that all (practical) languages "are flawed." And there are things I appreciate about all of the above languages (...except Tcl/Tk), even if I don't "like" the language overall. But I sincerely believe that statements like "all languages are flawed" and "use the best tool for the job" tend to imply that all (modern, mainstream) languages are equally flawed, just in different ways, which is absolutely not true. And in particular, it used to be true that all languages made tradeoffs between a fairly static, global set of binary criteria:
Looking at these, it's pretty easy to see where most of the languages in my list above fall on each side of each of these criteria. What's special about Rust is that the core language design prevents a relatively novel set of tradeoffs, allowing it to choose "both" for the first two criteria (though certainly not the latter three; the "ease-of-use" one is debatable) at the expense of higher implementation complexity and a steeper learning curve.
The great thing about this isn't that Rust has "solved" the problem of language tradeoffs. It's that Rust has broadened the space of available tradeoffs. The assumption that safety necessarily comes at a runtime cost was so pervasive prior to Rust that some engineers still believe it. But now, Rust has proven, empirically, that this is not the case! And so my ultimate hope for Rust isn't that it becomes ubiquitous; it's that it inspires even better languages, or at least, more languages that use concepts Rust has brought to the mainstream (such as sum-types) as a means to explore new design tradeoff spaces. (The standard example here is a language with a lightweight garbage-collecting runtime that also has traits, sum-types, and correct-by-default parallelism.)
There are other languages that, based on what I know about them, might inspire the same type of enthusiasm if I were to actually use them more:
...but, with the exception of Swift, these are all effectively "niche" languages. One notable thing about Rust is that its adoption has actually been rather astounding, by systems language standards. (Note that D and Ada never even got close to Rust's popularity.)
It would be a valid point if he weren't literally speaking over the people trying to tell him that they're not demanding he learn Rust: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548
Oh jeeze, you have no idea. You can watch it yourself: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548
That timestamp is about where the audience member (a maintainer of ext4 and related utilities) starts speaking. The "here's the thing" quote is around 28:40.
First and foremost _____ is a giant hack to mitigate legacy mistakes.
Wow, every article on web technology should start this way. And lots of non-web technologies, too.
Rust is extremely geared toward maintainability at the cost of other values such as learnability and iteration speed. Whether it's successful is of course somewhat a matter of opinion (at least until we figure out how to do good quantitative studies on software maintainability), and it is of course possible to write brittle Rust code. But it does make a lot of common errors (including ones Go facilitates) hard or impossible to replicate.
It also strongly pushes toward specific types of abstractions and architectural decisions, which is pretty unique among mainstream languages, and is of course a large part of what critics dislike about it (since that's extremely limiting compared to the freedom most languages give you). But the ability for the compiler to influence the high-level design and code organization is a large part of what makes Rust uniquely maintainability-focused, at least in theory.
That's true in C as well, though. This is what people mean when they say things like "undefined behavior can result in time travel".
The difference is twofold:
unsafe code are not completely formalized yet. This means that there are open questions about whether particularly complex patterns in unsafe code will be guaranteed by future versions of the compiler to be sound. Conversely, the C and C++ spec are generally sufficient to determine whether any particular piece of code has undefined behavior, even if actually analyzing it to find out is not possible automatically using existing static analysis tools.
"Heartbreaking: the worst person you know just made a great point"