Hacker News Reader

Comment by PoignardAzur | Hacker News Reader

> 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...?

View on HN

Most likely because they didn't know how to properly make multi-stage container builds. Probably downloading and compiling the crates on every push.

If 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.)

The 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]

I 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?

Remote development maybe. IDE locally, compilation and execution remotely.

Reply on news.ycombinator.com