Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Go to Rust

corrode.dev

Post reply on HN
Print view View original

241–250 of 544 posts

Re: Migrating from Go to Rust

#241

Post by Ygg2 »

Animats wrote: post #6

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

Go also has one glaring disadvantage. GC. Assuming you're in the cloud.

It's easy to write code that trivially eats memory. Plus any resources spent on it, are resources not spent on other cloud provider things.

Re: Migrating from Go to Rust

#242

Post by dbdr »

treavorpasan wrote: post #41
Thaxll wrote: post #31

Earlier quoted context omitted.

I don't see any reasons to use Rust when your team successfully shipped and is confortable with C#/Java/Go ect ...

If anyone one comes and tells me we need to rewrite in a new language from any of those modern languages, other than you are dealing with something cannot wait for GC. That is a signal that person is lacking purpose in their job or life.

GC pauses are not the only reason. At the very least, raw compute performance and lower memory usage are also valid reasons in some contexts.

Re: Migrating from Go to Rust

#244

Post by x-yl »

mountainriver wrote: post #178
Animats wrote: post #6

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

In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust.

They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static MutexOf course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .clone() and an Arc> means they will spend minutes 'thinking' about basic lifetime issues until I step in and add the missing `move` in a closure.

Re: Migrating from Go to Rust

#245

Post by SkiFire13 »

dnautics wrote: post #108
dwattttt wrote: post #72

Earlier quoted context omitted.

A &(dyn Error + 'static) should be fine for that; you don't need any allocated/variable sized data in a memory allocation failure.

stacktraces? might also be useful to know whether or not the latest allocand was a jumbo sized allocand that caused the failure?

And how do you store a stacktrace without allocating?

Re: Migrating from Go to Rust

#246

Post by vishnugupta »

fauigerzigerk wrote: post #237
bottlepalm wrote: post #182

Earlier quoted context omitted.

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.

IMO neither Go nor Rust are great for reading/reviewing code. Go is too verbose and the type system isn't expressive enough. Rust code is littered with little memory management details and it requires tons of third party libraries. I think coding agents will eventually be able to get the low level details right on their own. Reviewers should be able to focus on architecture, design and logic mistakes. I also think we…

> I also think we need a high level formal specification language to tell agents what we expect them to do.

Let’s make that specification Turing complete while at it.

Jokes aside, IMO it will be a good natural progression. Specify the problem statement in LLM specification, generate the code in Go/Rust whatever is the language of your choice and review the generated code to make sure it adheres to the architecture/design principles that you have set.

Re: Migrating from Go to Rust

#247

Post by kubb »

tptacek wrote: post #74

This is a weird document that is simultaneously trying to serve as a migration guide and an advocacy document for Rust. Ultimately, if you have to ask , the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". A generation of Rust programmers has convinced itself that "managed runtime" is bad, that not having one is an important feature. But that's obviously false: there a…

It feels like you’re upset because your favorite language has objective flaws that people are pointing out. You’re also trying to minimize people’s lived experiences and pleading with them to stop pointing the flaws out.

Sure, Go is better than Python in some things. But developers deserve the best. We deserve not to have to deal with Go’s quirks, idiosyncrasies and design mistakes.

Re: Migrating from Go to Rust

#248

Post by adeptima »

x-yl wrote: post #244
mountainriver wrote: post #178

Earlier 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…

In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust. They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .…

same experience. any good claude skills to ease the pain?

Re: Migrating from Go to Rust

#249

Post by IshKebab »

swiftcoder wrote: post #218
Animats wrote: post #6

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

> Rust has three main error systems (io::Error, thiserror, and anyhow), which is a pain when you have to pass them upward through a chain of calls anyhow explicitly isn't designed for what you are trying to do here. It's designed to be the last link in the chain (and complementary to thiserror, not in competition). If you are using anyhow any deeper than your top-level binary crate, you are likely to be in for an unp…

He was talking about the chain of function calls not crates. You still have that in your top level crate.

Re: Migrating from Go to Rust

#250

Post by Recursing »

com2kid wrote: post #86
tptacek wrote: post #74

This is a weird document that is simultaneously trying to serve as a migration guide and an advocacy document for Rust. Ultimately, if you have to ask , the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". A generation of Rust programmers has convinced itself that "managed runtime" is bad, that not having one is an important feature. But that's obviously false: there a…

Us Node folks adapted typescript because we wanted static compiled types. I wish TS had more of a runtime. The only thing I'm jealous of with regards to python is how seamlessly you can do JSON schema enforcement on HTTP endpoints. The Zod hoops are a constant source of irritation that only exists because the TS team is dogmatic.

express-zod-api works well for me https://github.com/RobinTail/express-zod-api I'd say about as well as anything Python
Post reply on HN