rust VS Rustup

I am very sorry, but you do not address that TBAA, like C has by default, generally is easier than just no aliasing, like what Rust has for mutable references. This is a major difference. C code can opt into a similar kind of aliasing, namely by using _restrict_, but that is opt-in, while it is always on for Rust.

And there is newer UB as well in Rust stdlib

https://github.com/rust-lang/rust/pull/139553

Real-world programs can be verified by formally proving properties on a small part of the code (called the kernel) in a way that transitively guarantees those for the remaining code.

For example, Rust's borrow checker guarantees* memory safety of any code written in Rust, even a 10M+ LOC project. Another example is sel4, a formally-verified micro-kernel (https://sel4.systems/About/seL4-whitepaper.pdf).

* Technically not; even if the code doesn't use `unsafe`, not only is Rust's borrow checker not formally verified, there are soundness holes (https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3A...). However, in theory it's possible to formally prove that a subset of Rust can only encode memory-safe programs, and in practice Rust's borrow checker is so effective that a 10M+ LOC project without unsafe will still probably not have memory issues.

Backend: Rust

What's weird about this?

To understand what evil_lincoln is doing, you have to understand very old Rust. Here's the commit that introduced it: https://github.com/rust-lang/rust/commit/664b0ad3fcead4fe4d2...

    fn evil_lincoln() {

Side note: There's an effort to cache proc macro invocations so that they get executed only once if the item they annotate hasn't changed: https://github.com/rust-lang/rust/pull/129102

There are multiple caveats on providing this to users (we can't assume that macro invocations are idempotent, so the new behavior would have to be opt in, and this only benefits incremental compilation), but it's in our radar.

Rust: Install it from the official Rust website.

It seems like that will change in the (near) future according to the following github issue[0]. A quote from one of the developers, rami3l, in that thread[1]:

> My current plan is indeed to remove implicit installations entirely.

[0]: https://github.com/rust-lang/rustup/issues/3635

[1]: https://github.com/rust-lang/rustup/issues/3635#issuecomment...

I got it to finally work by following this

If you are someone actively using such relative-path toolchains, please contact us (Discord / Github issues).

We had a snap package; we removed it in mid 2022

I don't know. The PR references prior discussion without a link, so it may have been private.

As long as he doesn't put hidden folders in your root like rust. https://github.com/rust-lang/rustup/issues/341

I think you're being upvoted by folks who don't know better, which is a shame because you're making things up :/. The telemetry feature in rustup kept everything local and never "pinged home". And you had to enable it with a command `rustup telemetry enable`. And it just logged JSON files at the path you mentioned. By 2019, the feature was disabled (see: https://github.com/rust-lang/rustup/issues/341 ) because no one worked on it and it just gathered bugs.

FWIW, there is a proposal to add telemetry to LLVM [0] and Rust used to have telemetry [1], both off by default. Some things in the node.js world have telemetry enabled by default, like Next.js [3].

Some people are posting here as if this as already decided -- AFIACT, that's not the case. It's not even a formal proposal yet, and the stated intent was to start a conversation around something concrete. (For context, this is standard for how I've seen the Go project approaches large topics, including for example I think there were something like ~8 very detailed generics design drafts from the core Go team over ~10 years).

It sounds like the Go team is going to take some time to look into some of the alternative approaches suggested in the feedback collected so far.

In any event, this is obviously a topic people are very passionate about, especially opt-in vs. opt-out, but I guess I would suggest not giving up hope quite yet.

[0] https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/6458...

[1] https://github.com/rust-lang/rustup/issues/341

[2] https://nextjs.org/telemetry

Rust (Specifically Rust Up) seems to have planned to include telemetry but they paused and cancelled the decision, possibly after implementing it initially.