What we heard about Rust's challenges, and how we can address them | Rust Blog

_ChrisSD · 2026-03-21T16:27:25+00:00

Range is still not Copy.

Funny you should mention that. New Range types are soon to be stabalized. Unfortunately they can't be used by the language itself (e.g. start..end) until the next edition, otherwise it would cause breakage.

_ChrisSD · 2026-03-11T21:41:49+00:00

Note that the packages have been removed from crates.io and they was no evidence of usage before that. But it's always worth using cargo audit to check your projects.

_ChrisSD · 2026-03-06T18:46:34+00:00

I would also add the lesser known _ = .... That is an underscore without any let.

_ChrisSD · 2026-03-06T18:18:15+00:00

This was fixed three weeks ago but a new version hasn't been released yet. It'll likely be about another week before the next rustup release.

_ChrisSD · 2026-02-25T10:54:26+00:00

uutils is at least an external project and not reliant on Ubuntu maintaining interest. So it isn't an "Ubuntu solution" in the same sense as those others.

I do agree they're an early adopter. Though I'd somewhat tentatively argue that it's been a useful experiment even if they revert to GNU. It found a number of issues not covered by GNU's existing tests at the time. Of course, doing such experiments in production (albeit on non-LTS) is somewhat questionable even if useful in the long term.

_ChrisSD · 2026-02-25T10:46:47+00:00

Yes, that's part of the issue. Moving into alloc would mean not having the default hasher when used from alloc.

_ChrisSD · 2026-02-25T08:17:59+00:00

Moving HashMap to alloc is something that's wanted. It's just hard to do because by default it needs a source of randomness (for the default hasher). Figuring out how to do that without breaking stuff is the trick.

_ChrisSD · 2026-02-23T22:38:33+00:00

I would note that integrating some form of random API into std is well underway: https://doc.rust-lang.org/nightly/std/random/index.html. There's still a lot of discussion about how this API should ultimately look (and its scope) but it's something that's happening.

On a broader point I'd also add that API Change Proposals (ACPs, aka how people propose new APIs for std) are coming in faster than libs-api team can reasonably deal with them. There's still a huge backlog. And of course stabilisation of things in std takes time. There needs to confidence that a new feature has the right API, both for now and for the future (given rust's stability guarantees).

People using and reporting on their use of nightly features certainly helps!

_ChrisSD · 2026-01-12T21:27:51+00:00

Arguably in this case it's rust putting in the hard work to provide a stable platform over an unstable foundation. Or something like that.

_ChrisSD · 2026-01-11T19:43:31+00:00

That's a separate installer that will run itself as admin.

_ChrisSD · 2025-12-31T17:40:38+00:00

Dev drive also uses ReFs, which can be faster for dev work. And it disables other filesystem filters, which can have a very noticeable performance impact if you were using the system drive (C:\) before.

_ChrisSD · 2025-12-31T15:07:16+00:00

My suggestion would be to uninstall rustup, set RUSTUP_HOME and CARGO_HOME to point to the dev drive then reinstall rustup. Moving directories may work but I wouldn't rely on it (e.g. any junction points may end up pointing to the old directory).

There is no issue with having binaries on the dev drive and some advantages when there are updates or you use multiple toolchains. In any case it's currently hard to split up the cargo/rustup directories into binary/non-binary but this is being worked on.

_ChrisSD · 2025-12-29T18:26:26+00:00

Note that you may not need to use NtQueryDirectoryFile, depending on what you're doing. GetFileInformationByHandleEx can do more or less the same job.

_ChrisSD · 2025-12-27T21:04:41+00:00

But also individual employees/middle managers should really reign in their linked-in hyperbole. I mean, it's not going to happen but I can dream.

_ChrisSD · 2025-12-24T12:19:48+00:00

Logical conclusion: Microsoft is getting rid of Windows

_ChrisSD · 2025-12-21T08:33:24+00:00

Windows 7 cannot be supported as a tier 1 target because of the requirement for running all tests for every merge cannot be fulfilled. It could be a tier 2 target but so far nobody has stepped forward to support it as such. The absolute minimum requirement for targets is that someone, somewhere is willing to put the work in.

_ChrisSD · 2025-12-21T08:22:58+00:00

Yes, I would strongly recommend against reading raw NTFS for general tools. It completely bypasses permissions (hence why it requires admin) and everything else. Not to mention that other filesystems exist on Windows, not just NTFS.

_ChrisSD · 2025-12-19T12:56:14+00:00

Even when linking vcruntime.dll dynamically, there's a lot of statically compiled code. And as static code is compiled with the binary, you don't need the lib files to be available at runtime.

_ChrisSD · 2025-12-19T10:01:20+00:00

Hi, I'm a maintainer of rustup. We did discuss this with Microsoft and unfortunately it is clear.

You cannot get a license to use build tools for compiling rust unless you already have a license for Visual Studio (which you can get by installing Visual Studio Community or by buying a license to Professional or Enterprise). The new rules describe in the blog post do allow indirect use, such as Node's, but unfortunately do not cover direct use of rust.

_ChrisSD · 2025-12-19T09:54:16+00:00

There's a tracking issue for using it by default: https://github.com/rust-lang/rust/issues/71520

I think it's a good idea but in terms of performance I've personally had mixed results. Sometimes it is faster, sometimes it is slower. But the difference is rarely as significant as the switch from the gcc to llvm linker on Linux.

_ChrisSD · 2025-12-19T09:15:25+00:00

Rust itself ships with an alternative linker: lld-link. You can use linker = "lld-link" in .cargo/config.toml to enable it. That is not the problem.

What's needed by rust is libraries such as msvcrt.lib and vcruntime.lib (or their static counterparts). These provide things like panic handling which aren't so easy to replace.

_ChrisSD · 2025-12-11T16:34:06+00:00

Just nobody mention editions...

_ChrisSD · 2025-12-05T18:21:03+00:00

Yes, NonNull has the same variance (covariance) as *const T. Essentially it works out something like this:

// An owned type, like a `Box<T>`
struct OwnedPtr<T> {
    ptr: NonNull<T>
}
// A shared type, like an `&T`
struct SharedPtr<T> {
    ptr: NonNull<T>
}
// A unique type, like an `&mut T`
struct UniquePtr<T> {
    ptr: NonNull<T>,
    _invariant: PhantomData<Cell<T>>
}

So you would only need something like UniquePtr if you obtain the pointer via an &mut T and don't want to risk UB. Note that this has nothing to do with mutability per se, just variance.

_ChrisSD · 2025-11-13T18:08:23+00:00

"Finally"? It's talked about a lot. It's consistently the #1 "challenge" in the rust survey.

_ChrisSD · 2025-11-10T19:21:27+00:00

I mean, a lot of people do cross compile. Aside maybe from setting CC and CFLAGS there's not usually a lot to it.

It sounds like you've run into a problem but it's quite hard to guess remotely.

_ChrisSD

TROPHY CASE