That's almost certainly per server instance though, there's no mention of any type of synchronization across multiple instances, so if you e.g run many small ones or run the service as a lambda I'd be surprised if it worked like you expected.

At that point you should be rate limiting at the reverse proxy or load balancer.

- Nginx https://blog.nginx.org/blog/rate-limiting-nginx

- Caddy https://github.com/mholt/caddy-ratelimit

- Treafik https://doc.traefik.io/traefik/middlewares/http/ratelimit/

IMO Lambda is kind of an unfair example because the author doesn't mention having multiple instances. Plus a hot take I have is you should not be building an entire web-app as a Lambda or series of Lambda functions... AWS does not have solutions for load balancing in things like APIG so you would have to architect that via DynamoDB or ElastiCache which is the "extra layer or two of overhead" the author mentioned.

We're also struggling with this, as we'd love to e.g. just run a formatter and commit the changed code in CI rather than just fail the code.

I tried Aider recently to modify a quite small python + HTML project, and it consistently got "uv" commands wrong, ended up changing my entire build system because it didn't think the thing I wanted to do was supported in the current one (it was).

They're very effective at making changes for the most part, but boy you need to keep them on a leash if you care about what those changes are.

Whoa! Small world. That was a fun story.

I think it depends on how thorny the thing you need to debug is. Race conditions, intermittent bugs that crash the process leaving no trace, etc. Debugging is much more than using a debugger

I like to differentiate between “bugs that stem from a recent code change” (easy to fix) and “bugs that suddenly appear out of nowhere” (hard to fix)

That was an incredibly interesting read, thank you for sharing!

Does it? Nobody's arguing that trans women are female.

Actually in recent years, there are many people who argue exactly that.

Their claim being that taking medication to suppress testosterone and boost estrogen, as well as having various cosmetic surgeries (castration, inversion of penis, bone/cartilage/soft tissue reshaping of facial features), gives these males a "female body".

Some of these males even claim to no longer be trans as a result of these surgical and pharmaceutical interventions, referring to themselves as "cis women".

I don't really think we have. There are many open source projects that duplicate work for a variety of reasons. Perfectly fine for stuff you want to do, but probably not an optimal allocation of resources

Aw, I hoped for a second for global coverage.

,$

I wonder if these graphs capture the new multi-threaded frontend that's on nightly.

These graphs only include stable releases, not nightly ones. Since the multi-threaded frontend hasn't landed on stable yet, we can't see it's effect on these graphs.

genuine question: how much can the frontend really impact compile times at the end of the day? I would guess most of the time spent compiling is on the backend, but IANA compiler engineer

> How much can the frontend really impact compile times?

Your question is addressed in this blog post - Faster compilation with the parallel front-end in nightly (https://blog.rust-lang.org/2023/11/09/parallel-rustc.html). One the example shown there:

- Serial took 10.2 seconds in the frontend and 6.2 seconds in the backend.

- Parallel tool 5.9 seconds (-42%) and 5.3 seconds (-14.5%).

So to answer your question, parallelising the frontend can have a substantial impact.

You are right that frontend is only a subset of the total compilation time - backend and linking time matter too. Happily, that's something that's being worked on too!

There is an alternate backend called cranelift (https://bjorn3.github.io/2024/11/14/progress-report-nov-2024...) that compiles faster than LLVM, at the cost of producing slower binaries. That's a good trade-off for debug builds.

And there's work on changing the default linker to lld (https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-l...).

We may see all 3 efforts land in the next year :)

One obvious example of this would be C++, where a smarter frontend that doesn't do textual inclusion of a million lines would significantly improve compile times.

But that's low-hanging fruit "optimization", no? Once you get around it, and this has been forever, the bottleneck is in the backend generation. So if Rust has already solved this, the area where they can improve most is the backend generation?

Most C++ builds I have worked with, and all of them being MMLoC codebases, were actually bottlenecked by the high memory pressure. In part due to heavy templates and symbol visibility.

I think the history of C++ implementations shows that it's not low hanging fruit, it's a huge effort to implement and the payoffs aren't game changing.

Modules? Yeah, I don't expect them to be a game changer either. Exactly because of the reasons I mentioned.

that makes sense. are Rust's macros handled in the frontend? if so, I could see how multithreading could have a dramatic impact