Why I Switched from Rust to Go on the Back End | Hacker News Reader

Why I Switched from Rust to Go on the Back End

levelup.gitconnected.com

40 pointskristoff_it18 comments

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.

Well written, Go’s sweet spot is definitely APIs and CLIs, Rust just has a bit too much overhead for this stuff unless you really need the performance

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

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?

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

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

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 really do not understand your problems with building in containers.

It's development, just cache target/ or COPY binary.

Yes, compiled managed languages are much better suitable for distributed computing workloads.

Leave Rust for use cases where no form of automatic memory management is desired.

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.

Can someone outline the benefits vs Node?

Go compiles faster than Rust.

Go and Rust can create one server binary.

Node dependencies can have thousands of files.

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.

Why not Zig though?

Zig is very early in its development and it doesn't have the same level of support, ecosystem, maturity, stability, mindshare.

It’s also not safe the way Rust and Go (and Python and JavaScript, etc) are.

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.

Why not Nim, C#, Java or Julia? Or php for that matter? Familiarity, libraries, community support.

Reply on news.ycombinator.com