5 ms·
> I have two options: either throttle my whole computer by spinning up a massive image for Rust to compile in, or deal with 3+ minute compile times. My dev cycl
by PoignardAzur 4y ago
> I have two options: either throttle my whole computer by spinning up a massive image for Rust to compile in, or deal with 3+ minute compile times. My dev cycle grinded to a halt, and I felt incredibly unproductive. I tried changing my workflow to write the code and the test before manually testing, or to not use auto-hot reload, but I felt cripped. I just couldn’t do it.
Can someone explain that part to me like I'm an idiot?
I don't get it. Compiling the project is slower on a container because...?
- AdamJacobMuller 4y agoI don't understand it either, but, perhaps he means that because the compile time of rust is longer, that the issue of hot reloading causing many many builds is exacerbated?
- ttfkam 4y agoMost likely because they didn't know how to properly make multi-stage container builds. Probably downloading and compiling the crates on every push.
- foldr 4y agoIf he's on an M1 Mac, he might still be using x86 docker images, which would incur some overhead on top of the usual overheads of virtualization. (I know that Docker doesn't inherently require virtualization, but it does on Mac.)
- unfunco 4y agoRemote development maybe. IDE locally, compilation and execution remotely.
- BFLpL0QNek 4y agoThe author is probably compiling inside an x86 container on his Mac M1. Doing anything in an x86 container/vm is extremely slow on the Mac M1 as it’s arm64 not x86. That specific issue is nothing to do with Rust. Why the author is doing this I do not know. Rust does cross compilation fairly easily out the box. If the author needs an x86 Docker image they can compile an x86 static binary without Docker then copy the binary in to the container. It’s a trivially simple workflow and you end up with tiny Docker containers. FROM scratch COPY target/my/binary /bin/binary ENTRYPOINT [/bin/binary]
- deleted 4y ago[deleted]