rust VS Rustup

See for example https://github.com/rust-lang/rust/issues/63818 and https://github.com/rust-lang/rfcs/pull/3467

Basically the problem is that async blocks/fns/generators need to create a struct that holds all the local variables within them at any suspension/await/yield point. But local variables can contain references to other local variables, so there are parts of this struct that reference other parts of this struct. This creates two problems:

- once you create such self-references you can no longer move this struct. But moving a struct is safe, so you need some unsafe code that "promises" you this won't happen. `Pin` is a witness of such promise.

- in the memory model having an `&mut` reference to this struct means that it is the only way to access it. But this is no longer true for self referential structs, since there are other ways to access its contents, namely the fields corresponding to those local variables that reference other local variables. This is the problem that's still open.

Rust Programming Language

AFAIK it's just waiting on the fix in https://github.com/rust-lang/rust/pull/114489 to land, I don't know of any other blockers.

- Async traits: coming soon https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizin..., actively in development (and has been for a while now, please don't confuse "this problem is hard and taking a long time" with "we don't care about this problem" https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%...).

- async `Drop`: there have been multiple "false-starts", trying to come up with an acceptable design. We don't have a good answer for this at the moment. It is unknown to me how long it might take for us to figure it out.

- TAITs: same as async traits. It'll likely land after async fn in traits, but it's part of the same design and implementation effort.

- variadic generics (unlikely they will every be implemented): agree with your assessment, at least in the short to medium term.

- generic closures: same as above.

- optional/named parameters: I believe that this feature as such might never exist in rust but think that a combination of structural structs (`struct { bar: usize, baz: usize }`) and/or struct literal inference (`let x: S = _ { bar: 1, baz: 2 }`) and default const values in structs (`struct S { foo: usize = 42, bar: usize }`/`S { bar: 0, .. }`) would be more generally useful and would nicely cater to this use case (`foo(_ { bar: 42, .. }`).

- anonymous enums: I want this as well, but it interacts poorly with type parameters and automatic type upcasting (if you have `A | B` can you convert it into `A | B | C`? Does it need syntax? What about `Result<(), ()> | Option<()> | Result`? If you have a function that returns that, what does `return Err(())` do?). Type downcasting could be done by forcing a match expression on the value. Whether `A | B` should `impl T` if `A: T, B: T` is an open question. I want to push for a solution here in the coming year.

> from my totally uninformed bystander perspective, there's been a sharp drop in people working on the language and compiler full-time since around Mozilla layoffs, and Rust still hasn't recovered from that

In terms of number of commits to the rust-lang/rust repo, activity peaked in late 2019/early 2020, whereas the Mozilla layoffs took place in late 2020. Activity since late 2020 has mostly stayed stable, and remains well above where it was at any point prior to 2018: https://github.com/rust-lang/rust/graphs/contributors

In addition, I know of several former Mozillians who remain employed to work on Rust, including one who heads the Rust team at Amazon.

As far as the number of contributors to each release, it's currently hovering around an all-time average high (although a handful of past releases have anomalously high peaks): https://thanks.rust-lang.org/

Is it expected that a programming language would have ~9,000 open issues?

https://github.com/rust-lang/rust/issues

The good news is that the Rust project has recently agreed to write a specification, and has a budget to hire an editor for it.

The less good news is that it's likely to take a long time before anything resembling a complete description gets written.

You can follow its status at https://github.com/rust-lang/rust/issues/113527

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

Hmm. No motivation description in the commit. https://github.com/rust-lang/rustup/pull/3044/commits/f887c19082eca77f33db282ca87eb3706c444098

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

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.

https://github.com/rust-lang/rustup/issues/341 and rust installation uses telemetry

Done https://github.com/rust-lang/rustup/issues/3197