When I clicked on it here in HN, that URL (with localhost:4321) was where I went.
Either someone's edited that since then, or a weird auto-redirect on your server happened.
eveeifyeve · 23h ago
Weird idk blame cloudflare.
echelon · 23h ago
I love the auto-playing music. It reminds me of the Geocities-era web.
andrewflnr · 22h ago
Did you actually like it back then?
ben_w · 22h ago
Back in the late 90s Geocities era, I did like surprise music on personal pages… but also I had bad taste in music at that point because I was an edgy goth teenager with limited experience.
None of us kids back then were any better.
The teachers were going to physically cut the speaker wires in each machine in the computer suite due to all the out-of-sync MIDI renditions of Beverly Hills Cop / Axel F theme before they figured out another solution.
ameliaquining · 21h ago
I'm confused about a couple things:
* What is metadata_decode_entry_impl_trait_header and what does it have to do with proc macros? I suppose if a proc macro emitted code that used impl Trait a bunch then it might need to use this code, but I don't see why that would disproportionately affect compile times.
* What's the proposal for how to fix this?
eveeifyeve · 21h ago
It's used to compile proc macros. in order to fix this typeck needs to not use them which is a huge rewrite alone.
ameliaquining · 11h ago
In what specific sense is metadata_decode_entry_impl_trait_header "used to compile proc macros" and where did you find this information? And what does the article mean by "and finally it can be fixed"?
piinbinary · 23h ago
I wonder why procmacros are slow. Can the compiler interpret them or does it have to go to all the work of compiling them before they can run?
Philpax · 23h ago
It has to compile them; you can see the compiled binaries in your `target` directory. Rust doesn't have an interpreter for the full language, only for the `const` subset, so it can't interpret them.
There have been some proposals to compile the proc-macros to WASM and share those alongside the code in crates.io, but nothing substantial has come of it.
LegionMammal978 · 22h ago
It does have an interpreter for the full language, that's what Miri uses [0]. In fact, Miri doesn't even have its own evaluator, it just adds additional features to the rustc const-evaluation. The big limitations are that it doesn't have much support for syscalls or other calls into non-Rust code, and it emulates all multithreaded code on a single thread.
That is an implementation detail, but yeah so far other areas have been given more priority.
LoganDark · 22h ago
> Rust doesn't have an interpreter for the full language
Ever since a while ago, rustc uses Miri for const evaluation. So there are a lot of things it can do that it used to not be able to do. But, yes, const evaluation is limited to things that are part of the `const` subset.
LegionMammal978 · 22h ago
As far as I'm aware, it's always been the other way around: Miri adds some features on top of rustc's const-evaluation code. The limitations of the latter are mainly self-imposed, due to the issues of exposing the different runtime models to programs. (E.g., you don't want to create allocations in const code that get deallocated at runtime.) Indeed, since 2019, the full functionality can be exposed with the unstable -Zunleash-the-miri-inside-of-you flag [0].
I'm pretty sure we're in agreement? Miri is capable of a lot more but there are self-imposed limitations on what you're allowed to do in const.
CodesInChaos · 22h ago
Is this complaint only about initial checks? Or also checks after a small change?
echelon · 23h ago
Feature request: Rust proc macros and compile time statistics need to be called out on crates.io
We're starting to ban them from our Rust monorepo.
kbolino · 20h ago
In order to collect reliable statistics on compile times, crates.io would have to be doing the compilation themselves. There's no way to trust telemetry from random users, both due to situational variability (individual machine load, overprovisioned CI runner VMs, overcommitted RAM, etc.) and malicious activity. That would mean a significant increase in hosting costs along with a slew of additional work to filter out spam, malware, and DOS attempts, plus building robust data collectors and aggregators.
As to proc macros, I don't think it's possible to implement derive without them. I think it would be fairly easy to detect their presence in a crate at least though.
Both things are also made more complicated by feature flags.
tayo42 · 23h ago
Doesn't that prevent you from using some of the most useful crates?
eveeifyeve · 22h ago
Kinda but there is good usage of proc macros and bad usage.
klas_segeljakt · 22h ago
#![forbid(proc_macros)]
burnt-resistor · 22h ago
Neat.
I use bacon with cargo-make to toggle between check, nextest+doctest, and a full series of pre-commit checks.
You're linking to https://eveeifyeve.pages.dev/http://localhost:4321/blogs/car...
You meant to link to https://eveeifyeve.pages.dev/blogs/cargo-check-slow.mdx/
Also, ew, auto-playing music.
Either someone's edited that since then, or a weird auto-redirect on your server happened.
None of us kids back then were any better.
The teachers were going to physically cut the speaker wires in each machine in the computer suite due to all the out-of-sync MIDI renditions of Beverly Hills Cop / Axel F theme before they figured out another solution.
* What is metadata_decode_entry_impl_trait_header and what does it have to do with proc macros? I suppose if a proc macro emitted code that used impl Trait a bunch then it might need to use this code, but I don't see why that would disproportionately affect compile times.
* What's the proposal for how to fix this?
There have been some proposals to compile the proc-macros to WASM and share those alongside the code in crates.io, but nothing substantial has come of it.
[0] https://github.com/rust-lang/miri
Ever since a while ago, rustc uses Miri for const evaluation. So there are a lot of things it can do that it used to not be able to do. But, yes, const evaluation is limited to things that are part of the `const` subset.
[0] https://github.com/rust-lang/rust/pull/56123
We're starting to ban them from our Rust monorepo.
As to proc macros, I don't think it's possible to implement derive without them. I think it would be fairly easy to detect their presence in a crate at least though.
Both things are also made more complicated by feature flags.
I use bacon with cargo-make to toggle between check, nextest+doctest, and a full series of pre-commit checks.