Migrating from Go to Rust

The article seems to be just a way to say "Rust is better" - and it fails to do so by spreading misinformation such as the channels part (https://corrode.dev/learn/migration-guides/go-to-rust/#chann...) or making a fair comparison of pprof vs Rust's flamegraph.

It also skips entirely over debugging (delve vs gdb), IDE support, ecosystem (why the hell does Rust have N async runtimes?!), statically linking and so on.

A comparison between the performance of RLS / rust-analyzer (painfully slow) and gopls would be enough to kill the whole argument about developer happiness and productivity.

It even passes traits as a "reason to switch" to Rust - where in fact it would probably be a reason (IMHO) not to use it (together with lifetimes).

I think both languages are amazing, so a migration Go -> Rust (or Rust -> Go) makes no sense most of the time.

I've written code in both for a while now, so I know the pain and advantages of both.

For example, Go sucks at microcontroller stuff - in fact it's not even Go officially (see my presentation about porting "Go" to an ESP32-S3 [1]) - whereas Rust is amazing and even has a strong project behind (https://esp.rs) and amazing tooling (probe-rs & co).

What's also not addressed here is the Go ecosystem. The Go packages are one `go mod add` away (pkgs.go.dev) and the module owner guarantees v1 backwards compatibility for the whole lifetime of the module. This means that, no matter what happens, your dependencies will always be up-to-date with no migration struggle. This makes creating stuff for anything around the Kubernets ecosystem a breeze, you can literally import the types from another project and start your integration right away.

The most valuable part of the article seems the link to the opposite view (https://blainsmith.com/articles/just-fucking-use-go/). They're equally biased, but one is more straightforward than the other.

All in all, it's not a fair comparison and it's very biased (which is fair) - at the same time I think the idea behind the article is "wrong". If you find yourself migrating from Go to Rust (or vice versa), you're likely doing something wrong - and the performance gain is not the reason you're really doing it for.

[1]: https://docs.google.com/presentation/d/18jWccV-F2FguZiB5gXLk...

[flagged]

[flagged]

[flagged]

[dead]

[dead]

[dead]

TLDR:

>The other prior worth disclosing: I run a Rust consultancy; of course I’m biased!

Rust is great. However in an agentic world go will win. Look no further than incremental build times. This, combined with high token costs mean that for a given application it simply will cost more to to write it in Rust than Go.

This can easily be justified for many usecases, but for your vanilla crud app, do you really need Rust?

Per the article, you are getting 20-50% better more performance with Rust. Not worth it unless your team was already fluent in Rust. Now consider a scenario where your team uses AI exclusively to code, now you are spending more time and tokens waiting around to consume large rust builds. As far as I know this is an inherent property of Rust to have its safety guarantees.

I think Rust makes sense for a lot of cases, but for a small web service, overkill and unnecessary imho. If someone ported their crud app from Go to Rust I would question their priorities.

Again I am speaking more in terms of software engineering economics than anything else. Yes, I know in a perfect world Rust binaries are smaller, performance is better and code more “correct”, but the world is hardly perfect. People have to push code quickly, iterate quickly. Teams have churn, Rust, frankly is alien for many, etc.