So out of the 3 points, 1 is not an actual problem, but just learning curve, 2 is a mostly complete, but slightly limited mocking library, and 3 is an unoptimized local dev/build process.
I actually think those are fair reasons to switch to something more straightforward for a solo dev, but none of these are true showstoppers and the story for each will get better in time. Good feedback on the Rust in general.
> 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...?
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?
I'm far from a Rust expert but isn't 1. Just solved with traits? And 3 seems more of a bad project structure they have chosen, containers have their place. But it's not local dev.
Javascript runs both at client webbrowser and Node serverside.
Go and Rust runs only serverside (if not transpiled to Javascript or WASM).
Like with any programming language, it depends are your required dependencies available for that programming language, with licenses that you would like.
Ha. In some areas it's actually safer. Very good null safety and static typing are two obvious things.
It also has memory leak and corruption detection in debug builds, and it's surprisingly accurate. For leak detection it's 100% accurate because of the level it runs at. You can even build with these checks for production if you're willing to take the performance hit.
I actually think those are fair reasons to switch to something more straightforward for a solo dev, but none of these are true showstoppers and the story for each will get better in time. Good feedback on the Rust in general.