panstromek

This is basically polymorphization, mentioned in the blog post. The prototype implementation is in progress.

I see, thanks. I assume `async-stripe` is auto-generated from some IDL, those crates sometimes bump into some pathologial pattern, I'll check it out.

`actix-web` itself should be fine, `sqlx` can be heavy if you use its compile time features, I'd assume `askama` is heavy as well, just based on the description (it generates rust code at compile time).

Otherwise it depends on how the code is structured (e.g. how generic it is, how deep types or complicated futures it creates).

Not sure if that's the name or a typo but I'm not gonna lookup that

I was also thinking about Move and Forget traits, which impact cancellation safety. I think those are at least somewhat soft-blocked on the solver, but I'm not sure. Honestly, you're probably much better contact to talk about that, this is out of my wheelhouse.

thanks, fixed ;)

> polymorphism

I assume you ask about polymorphization, which is a term used to refer to a specific optimization mentioned in the blog post.

The base version which Rust wants the most makes sense to enable by default for all builds, because it's purely just removing duplicate work - this is for cases like Vec<u64> and Vec<i64>, where we currently emit code for each one separately, even though it's pretty much the same for both.

More general version will make sense for debug builds or in some special cases, like when optimizing for size. I believe people also want to experiment with it for some interop use cases (and for that, it'd be useful to have source level annotation). I think it's too early to tell how all of this is going to look like, though.

20 minut definitely sounds suspicious. For comparison, Rust compiler takes ~10 minutes to build in release mode (in the simple config without all the fancy PGO stuff we run on CI).

Do you have some more info about the codebase, is it public?

There's some movement on specialization as well: https://goals.rust-lang.org/2026/specialization.html

It's not directly blocked on the solver, but getting the type system into a better shape definitely helps reasoning about the soundness issues involved.

I don't understandy why, but all submissions of this post so far had incorrect title. When I posted the correct one, it still got reassigned the wrong title and I had to edit it (and it didn't allow me to do that yesterday, only today).

It's deeper pipelining of the build units (similar to how CPU does pipelining). Rust has had pipelined builds for a while, but this extends it further.

We should ;)

Nice, excited to see that. This is basically deeper pipelining, IIUC. Nick (the author of the blog) implemented the current version of this "emit metadata sooner," optimization and already experimented with pushing it even sooner a while back.

We have discussed this briefly on last All Hands, the problem will probably be dealing with compiler errors, when they happen in builds that already emitted metadata. I believe this was the reason why it wasn't merged in the first place.

> there better support for incremental compilation

What do you mean by this?

btw. That could actually make it slower to compile. The compiler uses the orphan rule to short circuit some checks IIRC.

Nevertheless, people in the project are trying to figuring out a way to relax the rule while still maintaining coherence, so this might happen some day.

Servo also had some other novel architectural ideas IIRC, not directly related to paralelism, but it's been a while since I was looking into that, I don't remember much.

I think you severely underestimate how much effort goes into tackling the computation complexity of those problems as well. Multiple months (at least) went into tackling various exponential blowups in the next trait solver work. That's a typical symptom for NP-hard problems, there's a consistent stream of exponential cases for which you keep adding various fastpaths and caches for various patterns.

Various crates have explicit workarounds for these issues as well, typically using Box to avoid deep types, e.g. axum's `.route()` added it explicitly to avoid this, I believe.

For match exhaustivness, there's currently an active discussion on it again, because it comes up in derives for big enums, and we just landed an optimization that avoids it for some derive macros.

In other ecosystems, I remember a talk about avoiding exponential blowup for various constructs in C++ templates. Typescript even has a guide for how to write types to avoid complexity problems. With libriaries like `ArkType`, people hit these issues a quite a bit.

I won't claim that this is the majority of the compile time work, but it's something that comes up often enough that I think it's pretty ridiculous to say "the worst-case just doesn't occur."

> 2. Type checking (not all type systems)

> For (1) and (2), the worst-case just doesn't occur.

I don't think 2. is a good example to be honest, It happens quite a lot. At least it's definitely not in the same category as dependency resolution, where people often don't even know that it's NP-hard.

Typescript, Rust or C++ type system complexity is routinely a compile time problem that people have to work around or tackle from both sides (i.e. either changing the compiler or changing the program).

Asking on zulip is the good first step, yes. But RFC or MCP is only needed for bigger changes. Majority of changes will not need that, especially the ones contributed by newcomers.

It's relevant for C++ interop at least, but that's about it.

By default yes. Part of the work is figuring out how to get around that.

For everybody who doesn't have the context, just note that this is not an accepted langauge change. It's a just project goal, which means it's accepted as something people will work on, but the design might change significantly or it can even be abandoned completely (which is pretty unlikely for this one, to be fair).

Rust moderators are not anonymous.

This is difficult to answer, because these systems exhibit somewhat chaotic behaviour, and it gets even more complicated cross-crate. I was mostly talking about single crate scenario.

Since you mentioned libc, the likely answer is that nothing gets codegened in downstream crates. But this is only because libc functions are usually not generic or `#[inline]`. Changes to generic or inline functions can dirty downstream codegen units where the function was called. Inside `libc`, the change will trigger recompilation of at least one codegen unit, depending on how the function is used inside libc itself. Single crate is split into 256 units in incremental mode.

Nevertheless, even if the codegen is needed just for the `libc` crate, `libc` will dirty its metadata, which means that downstream crates will still need to recompile the initial steps before incremental kicks in (which is roughly parsing, macro expansion and name resolution). After that, the query system just returns cached results for all the subsequent steps.

There's some work going towards skipping the rustc invocation altogether in those cases (usually referred to as "Relink don't Rebuild" proposal), because even just loading the dependency graph and figuring out that you don't have to do anything can take quite bit of time for larger programs.

> GHC currently needs to parse+typecheck+codegen a file before it can process other files that import it. Codegen is slow. Thus, there's currently demand split compilation into "stages", so that the next file can be typechecked after its imports have been just typechecked (not codegenned).

> I would also enjoy if recompilation avoidance were to happen at the function level, not the file level.

This sounds like Rust is already doing a lot more incremental then GHC then. Rustc only needs to parse, expand macros and do name resolution. Everything else is incremental after that, on a very granular level.

Yes, and there is some compiler flag to do this, even though it's not 100% intended for this use (I think it's something like mir-inline-trheshold=0).

There's also -Zhint-mostly-unused flag.

The tradeoff is that these functions then have to be encoded in metadata for downstream crates, so it's not necessarily faster.

> To me compilers should be content-addressed databases.

There's a language called Unison that does that - and the "content" is the AST, so all functions that have the same shape are the same function. It's pretty interesting.

This is good diagnosis of the problem. I found that often the right solution is to ditch the hierarchy and use flat structure. I wrote about this some time ago: https://yoyo-code.com/embrace-flatness/

Big insight in that article is also from https://matklad.github.io/2021/08/22/large-rust-workspaces.h... about structuring large rust workspaces as a flat list.

Yea, when there's a match, our app stops playing videos in Spain and we get some bad reviews. It's pretty annoying.

I will join the others and say you should just leave twitter: https://yoyo-code.com/you-should-delete-twitter/