E.g. you cannot translate `#[repr(C)] struct Foo { v: i32, u: i32 }` to `typedef struct { int32_t v; int32_t u; } Foo;` because in Rust it's entirely valid to take a `&Foo` and view it as `&[i32; 2]`, while in C this is UB.
A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1.
But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.
It makes a big difference if you want to translate Rust to C. TBAA means you cannot translate a Rust struct to a C struct if you want to stay in standards-compliant C.
Depending on what your goal is. If it is eliminating trusting trust attacks, yes this is no enough. But more commonly you only want to compile rustc for a platform it was never compiled on, and for that this project is definitely enough.
Datalog is not used for borrow checking. It was used in old versions of the experimental next-gen borrow checker, Polonius. Current versions of Polonius (which is still experimental) are coded in Rust.
In C/C++ the default behavior, always, is very dangerous UB. Some compilers offer an option for guaranteed wrap-around, and some compilers offer an option for controlled crash. None of them is standardized or the default.
In Rust the standard mandates a guaranteed wrap-around or a controlled crash. The default behavior is crashing in debug mode and wrapping-around in release mode, but you can control that with a compiler flag.
No matter how you look at it, the Rust behavior is safer. The default behavior? Way better in Rust than in C++. Want a guaranteed wrap-around? In Rust, check. In C++, depending on the compiler. Want a guaranteed crash? In Rust, check. In C++, depending on the compiler.
Also worth noting that overflowing has much more severe consequences in C++ than in Rust, due to bounds checks.
> I don't know if Rust will ever attempt to fix this mistake
It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision.
> Is there anything similar to (or better than) overleaf for collaborating on typst docs? To be clear, overleaf isn’t all that great but I sometimes work with groups that are used to it.
Yes, https://typst.app/ is the official Typst app (part of how they make money).
> Have conferences that traditionally accepted latex source (and specified latex templates) started accepting typst as well?
I've heard this from other LaTeX veterans, but as someone that has never done any LaTeX himself and was scared by all those backslashes and braces, the simple C-like syntax is a blessing.
Rust and non-SPARK Ada are not equally safe. Ada is unsafe in the presence of data races, and also has runtime checks that slow it down, or you disable them and then it's even less safe.
But it is. It is true that Rust libraries could take this position of "any API misuse causing vulnerability is a CVE" more to the extreme, currently it is applied to memory safety but it could be applied to panics as well. However it is still true that pretty much all Rust libraries treat API misuses that cause UB as a CVE, and pretty much no C/C++ library does that, and that inflates the number of Rust CVEs.
> On the extreme end, we have compiler soundness bugs. I'm a bit of worried that I'm hitting any of those when I'm tweaking the types until the compiler no longer complains. Beyond the basics, I really don't have a grasp of Rust's type system rules. But I suspect they very difficult to hit by accident, and even if I do, the code must be miscompiled in meaningful, but difficult-to-notice way. All that seems rather unlikely, which is why these bugs aren't treated as vulnerabilities.
Rest assured that you are much more likely to hit a miscompilation in your compiler's backend, and that it is much harder to detect.
My understanding is that they claim that the average Joe writes code in a garbage-collected memory-safe language.
Which is... true? but irrelevant. Such applications are not suggested to be ported to Rust. Of course, some people still do that, because they like Rust; but that's their personal choice.
You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.
> Unsafe is not necessary to trigger UB in case no_std is used
I have no idea what are you talking about, no_std is just completely irrelevant here.
> Nor if one of the soundness holes in the Rust programming language itself is encountered
Have you actually examined those soundness holes? It is basically impossible to hit them without writing code which is meant to hit them.
And this is also noted in a footnote.
> Nor if there is UB in one of the libraries used as a dependency by the library you are using
If we treat a Rust program globally, this is kinda true. A more true statement will be that UB cannot happen without unsafe code somewhere, including in dependencies (and the original statement can be interpreted as saying that).
But the true power of unsafe is that it's local. If you've reviewed a library and its unsafe is sound, you can ignore it for the rest of the calculation. And of course, the more people review a library the more likely it is that it is sound.
> Which has happened many times, since the Rust standard library is full of unsafe
And here again the post's point stands: many CVEs in std are artificial, you can't exploit them without writing a program that is meant to be exploited. Such thing will never be a CVE in C/C++'s std.
> Rust also requires libraries to be safe regarding unsafe, no matter what kind of insane input that is given to the library and that would otherwise potentially be security issues. Which is too difficult for many library authors.
That is true, that is in fact the post's point: that if they fail this, a CVE will be filled, even if exploitation is just not possible realistically.
But there is a very simple solution for library authors: don't write unsafe code! You don't need to, the vast majority of times. And if you do not have the knowledge (which indeed is more complicated than in C/C++) how to not have an unsound API, then you just should not write unsafe code.