[flagged]
Migrating from Go to Rust
271–280 of 544 posts
Re: Migrating from Go to Rust
#272Earlier quoted context omitted.
Standard library is something you have to maintain for all eternity, with identical API. It had been argued that some concurrency primitives like channels would have been better outside of std (for rust, to be clear). Once dependency management is solved, a small std is beneficial.
Doesn't Rust already have that solved via editions? If anything, that's the language that's especially well positioned here.
I believe the stdlib can't be versioned like that: there's only one stdlib linked into a final artifact, you can't have two versions with differing APIs in there.
Re: Migrating from Go to Rust
#273Great writeup. The section on error handling differences is spot on, especially how Rust's Result type changes the way you structure application flow.
Re: Migrating from Go to Rust
#274LLM writing tells are getting more subtle, but they still jump off the page for me, in particular the word "genuine:" "This is the area where Go genuinely shines, and it’s worth being precise about why" "the lack of GC pauses is a genuine selling point" "Humans are genuinely bad at reasoning about memory" "There are cases where the borrow checker is genuinely too strict" tbc I don't think the article was fully AI-gen…
the psychosis has gone off the charts! anything that sounds odd to someone can now be labelled as an LLM text "smell"?
why scoff over someone doing assisted writing? i might age myself but kids back in the day would try to sound better by using synonym feature in ms word (or through web thesaurus) for their assignment essays. this all looks familiar to the same practice, now only made more accessible.
Re: Migrating from Go to Rust
#275Earlier quoted context omitted.
For me the main advantage of Go over Rust is compilation speed. Then compared with Go Rust still rely on many C and C++ libraries making it problematic to cross-compile or generate reproducible builds or static binaries. The minus side of Go is too simplistic GC. When latency spikes hit, there are little options to address them besides painful rewrite.
> Rust still rely on many C and C++ libraries Yes but Rust has a lot more availability of libraries to do stuff as a result. Want to do anything ML or scientific? You at least have a route in Rust where you don’t with Go.
With Go basic stuff like url parsing or HTTPS support is written in Go and comes with the standard library. With Rust too many necessary things are just wrappers around C and C++ making cross-compilation and reproducible builds much harder to archive.
As for availability if CGO is ok, then calling C or C++ code from Go is not that hard. Also, there is always an option to just start C++ process if extra data copies are OK.
Re: Migrating from Go to Rust
#276Earlier quoted context omitted.
I love Go and used to write it heavily for anything non LLM based. Now that we have agentic coding I just write everything in Rust and couldn’t be happier. The struggle with rust was writing it, go was made so it was easy to write for mid level engineers. Now that we have agentic coding I’m not sure Go’s value prop holds up anymore My rust services have been nothing short of amazing from a performance and reliability…
For me the bottleneck now is reading/reviewing code, not writing code. As you said, AI makes it way easier to write, but do you not review the code? And isn't a verbose, cryptic language with lots of nitty gritty memory management not harder to read/review? I'm not sold on Rust being a great language to use with AI unless the reason to use it is a lot more than just Rust being fashionable.
I find Go harder to review than Rust.
The verbose error handling diluting the interesting parts is one thing, but the main issue is the weak type system. Having to read the callee's code to check if it deviates from `res xor err`, or if it mutates its arguments. Figuring out which interface that `func (o *Obj) ()` is implementing, if any. Dealing with documentation that is a wall of 100 disappointing oneliners all repeating the function name.
Rust is information-dense and takes longer to master, but it's not inherently cryptic, there's a finite amount of things to know. Memory management sometimes take a bit of thought to write, but it's straightforward to review, you can trust it's correct if it compiles, you just keep an eye out for optimizations.
Re: Migrating from Go to Rust
#277I could see migrating from C or C++ or Python to Rust, for various reasons, but for web back-end work Go is a good match. I write almost entirely in Rust, but the last time I had to do something web server side in Rust, I now wish I'd used Go. The OP points out the wordyness of Go's error syntax. That's a good point. Rust started with the same problem, and added the "?" syntax, which just does a return with an error…
I don't fully get the argument about errors. in rust say a function returns Result so either the we get a result all an error how is that different from (int, err) in go? do you not still need to handle the error? in go you just return the error up to whatever the top caller is.
In Go you can ignore the error value though, and use directly the returned value (`int` in your example). In Rust you cannot do that, you need to unwrap the Result or use the `?`
Re: Migrating from Go to Rust
#278I write purely Go at $dayjob, but I write purely Rust in my projects.
I have a huge list of things that I have in Rust that I would like in Go, but I don't have a single thing I am missing from Go in Rust.
I grow tired of golang "dumb it down" approach as I find it actually just shifts more and more work onto me.
Is anyone in a different position? What does Go have that rust does not?
Re: Migrating from Go to Rust
#279TLDR:
>The other prior worth disclosing: I run a Rust consultancy; of course I’m biased!
Re: Migrating from Go to Rust
#280>Go developers don’t usually come to Rust because Go is “too slow.” For most backend workloads, Go is plenty fast. People are generally a bit frustrated with Go’s verbose error handling, the danger of segmentation faults from nil pointers, and the lack of generics (for a long time) or any sophisticated type system features, such as enums or traits. Interfaces are not a worthy replacement for traits, and the Go standard library has some weird gaps, such as the lack of a Set type. (The idiomatic workaround is map[T]struct{}, which works fine in practice but is a tell that the type system isn’t quite carrying its weight.)
If those are issues, I rather use C#/.NET than expose both developers and AI agents to a cognitive overload.
However, those are not big issues to me, and at least in the present day, Go seems to excel at the things it is supposed to: backend and microservices. Sure, you can find some small issues with Go if you are really nitpicking, but you can find bigger issues with other languages. Sure, Go is boring as f..k, but I don't care and the agents don't mind, they love Go. Most people prefer reading Go than reading Rust. Go allows a fast way to production and for many startups and small companies, that matters a lot.
I don't hate Rust, and even use it - for where I think it makes sense, but for backend and microservices, Go seems a better fit.
As always, this is an opinion, derived from my personal experience, take it with a grain of salt, your experience might be different.