mirrord VS sccache

So, you've been using mirrord to simplify your development process (if you haven’t, go here!). Naturally, you want the traffic from the app you're debugging to go through the cluster environment, so your app can communicate with its clustery pals. There is a problem though: your latest change adds some new columns to the database, and you don’t want to modify the database in the cluster and affect everyone else working on it. You do have a local instance of the database that you can modify, so your app can use that, but you still want it to talk to all the other components in the cluster. So what now? The new outgoing traffic filter feature is here to solve exactly this type of problem!

I had the pleasure of talking to Eyal @ CTO at Metalbear and the maintainer of Mirrord. I got some crazy insights.

If you want to take mirrord for a spin, check out the quick start guide. We’d love to hear about your experience or just general thoughts - chat us up on our Discord or open an issue or discussion on GitHub.

We're building an open-source tool called mirrord which lets you run a local process in the context of a pod in your cloud environment. We often get asked how mirrord is different from Telepresence and so we decided to write a short blog post about it, which we hope would be valuable to those interested in local Kubernetes development:

Hands-on tutorial of mirrord.dev with the creators and Rawkode!

if you are interested in k8s, iptables, hooking libc, asm etc https://github.com/metalbear-co/mirrord

I gave my first CNCF talk in Toronto yesterday, talking about https://github.com/metalbear-co/mirrord , how all the features work, and how it's engineered!

Worth noting that the first commit in sccache git repository was in 2014 (https://github.com/mozilla/sccache/commit/115016e0a83b290dc2...). So I suppose that what "happened" happened waay back.

If you have lots of shared dependencies, maybe try sccache?

I'm going to set up sccache [0] to use it tomorrow. We use MSVC, so EFS is off the cards.

[0] https://github.com/mozilla/sccache/blob/main/docs/S3.md

I think the primary benefit of pre-built procmacros will be for build servers which don't use a persistent cache (like sccache), since they have to compile all dependencies every time. But IMO improved support for persistent caches would be a better investment compared to adding support for pre-built procmacros.

Checkout https://github.com/mozilla/sccache

https://github.com/mozilla/sccache is another option which addresses the use cases of both icecream and ccache (and also supports Rust, and cloud storage of artifacts, if those are useful for you)

That being said a compilation cache, eg the de-facto standard for Rust: sccache (https://github.com/mozilla/sccache) will help to compile and store some of the build artifacts centralized - still for each crate version + build profile (RUSTFLAGS) combination.

That's definitely not my experience. Never had any issue running Rust on Windows. You just download and run rustup-init.exe, then updating is simply a matter of rustup update. Documentation generation is built in (cargo doc) and just a case of annotating code with triple-/ markdown comments and then running that command. sccache works fine for me (just need to set RUSTC_WRAPPER=/path/to/sccache). And the error messages from rustc are by far the best of any compiler I've used. Not sure how they're unhelpful, they tend to explain step-by-step what the problem is and how to fix it.