The eventual formalization of Rust and a creation of a formally proven compiler is presumably going to be the end point of this process.
I used to compare this hype to crypto hype, but its so much worse. Can we jusy like not try to shove llms into every single conversation.
Is there a hackernews type space where the word is banned? Even lobster.rs has this problem. I need some sort or way to just hide all content on certain sites where LLMs/AI are mentioned.
https://www.lesswrong.com/posts/zHhGa3iQBQcdSifFL/a-critical...
The reality is that if this were actually code that people wrote, well, it wouldn't have sat around for a decade.
The fact that nobody reported this before means it's not, by definition.
This is the problem when a language advertises with “guarantees” and it turns out it never had any due to many false assumptions by their promoters.
So what other soundness bugs are there in the language that we need to know about?
For some reason this is controversial, but it remains true.
- you've never written a custom Drop
- "Not really". Implying that your experience generalizes
I've written a bunch of rust programs without custom Drop. I believe your first statement. There are large classes of programs that don't need it. There are also many that do. I think your statement says a lot more about what kind of programs you work on than about custom Drop not being common. People are downvoting the implication that custom Drop is not a common pattern.
But not custom drops that are doing variadic type stuff like this, usually.
That it took 11 years for someone to come across this is a fairly intense counterargument to your attempt to paint this as a language with dangerous footguns.
Maybe they wrote it in C :-)
On a serious note, old software is generally more trustworthy than new software, because bugs are discovered over time and with usage.
struct Q<T: 'static>(Option<T>);
impl<T: 'static> Drop for Q<T> {
fn drop(&mut self) {
// Code in here has access to a non-'static &String
// but assumes that it's a &'static String
}
}
fn main() {
let l = String::new();
let mut q = Q(None);
q.0 = Some(&l);
}
It uses the same code, so yes.
(Although I don't know what are their guidelines, it might be that they require avoiding code relying on implied bounds, for example).
q.0 is the first field of q, which is anonymous. They could have just as well called it x and written q.x.
"q.0" is not really needed, it's a struct with unnamed fields. Here is the same with named fields:
struct Q<T: 'static> { pub x: Option<T> }
...
let l = String::new();
let mut q = Q { x: None };
q.x = Some(&l);With this you have to recompile everything
I will happily continue to write things in Golang first. I don't enjoy refactors in Rust, and it's rare that I see things that genuinely need its raw performance.
Cloudflare's Oxy is a stellar example of build in Golang till your design is settled and then port over for performance when you need it.
ETA: Downvoters, I salute you. Without your selfless courage, the forces of light humour would surely prevail.
EDIT: I don’t even think HN cared either up until now. If you search this paper on HN, guess who posted it?
Lets hope that this will be the only occurrence of soundness bugs in Rust and perhaps it needs a tiny disclaimer on claims of “safety guarantees”.
So I don't think it's fair to claim that "no-one cared".
Safe rust is safe, granting `unsafe` and compiler errors. This isn't a secret.
Specifically the `q.0 = Some(&l);` violating 4.15.2:40 ("An assignment expression requires that the type of its value operand is a subtype of the type of its assignee operand.")
I gave it a quick scan for Rust examples; there are 11 samples among the following pages:
The first thing I always look for is mutability (combined with some other tricky feature), e.g. "Now it's a Just(3):Maybe<Int>, now it's a Nothing:Maybe<Int>, now it's a Nothing:Maybe<String>."I wonder if TFA's example could be reproduced without mutability.
Also, a lot of those soundness issues aren't related to new features _at all_, but usually due to poor assumptions made in optimizations.
The soundness bugs _are_ taken seriously though, and are slowly being patched out. A lot of the links in OP are now closed because Rust either changed how it generates code to avoid the issues, or fixed LLVM.
hm, there's an effort but scoped only to the std
It's terrifically complex: https://doc.rust-lang.org/beta/nightly-rustc/rustc_middle/ty...
You can be annoyed by Rust fanboys, sure, but the more annoying are the Rust haters, because the hate always comes from a place of ignorance.
The hate only works if you don't go beyond a surface level understanding of Rust.
E.g. a niche case on the borrow checker is slightly broken, so borrow checking doesn't make sense.
Or the "oh but Rust needs unsafe, so it's just like C++".
Yeah, but by that measure all of C++ is unsafe++, even unsafe has more guarantees than standard C++.
Only if your whole understanding of the concept is that the keyword is called "unsafe", does that argument make sense.
A bit of a rant, but if you hate Rust with a passion, ask yourself first where that opinion comes from and if it can stand on its own. In most cases it can't.
- If a compiled C++ program has unsound behavior, the program needs to be fixed
- If a compiled safe Rust program has unsound behavior, the compiler needs to be fixed
1) Unsoundnesses in Java's type system are checked at runtime.
2) They (or at least some) are intentional or at least won't-fix bugs.
Both are not true for Rust.
Rust cannot fail, it can only be failed.
“Please build the perfect system. Because I specified ‘perfect’ any flaws are due to your incomplete implementation, not my awful brief.”
If the person writing the rust spec was a client I would have to drop them because they would be setting themselves up for dissatisfaction.
You can't do that with Rust because "Rust's type system" is literally just the vague concept of "a type system that is safe". The implementation of this ideal in rustc can have flaws, but Rust itself cannot, because Rust itself has no flaws by definition.
Sweet. But why should anyone care..