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

431–440 of 544 posts

Re: Migrating from Go to Rust

#431

Post by tredre3 »

repelsteeltje wrote: post #4
amusingimpala75 wrote: post #2

This is probably going to sound generic / repetitive, but my biggest complaint about Rust is the package management situation, which is entirely the result of the developer mindset. I love the ergonomics on the rust side (the functional approach to data types is beautiful), but I’m working on two projects side by side, one in rust and one in go at the moment. The dependency trees are entirely different beasts, with m…

Interesting. I'm not very familiar with Go. What is the equivalent for Tauri in Go's stdlib? Would it make sense to continue using Go for the frontend and doing only the backend in Rust for your user case?

Go's stdlib has none of the things GP listed. No sqlite3, no ratatui, no cli (though there is `flag` if it's enough for you), and no tauri equivalent in its stdlib. Those would be go-sqlite3, bubbletea, cli or cobra, and wails.

Charitably, I think OP meant to say that in the rust project only four dependencies were added and that caused 400 transitive dependencies to be pulled. Adding the four Go equivalent will still result in 10x less packages being pulled.

It's a culture problem, Go authors prefer solutions that are self contained, rust authors embrace the culture that gave us left-pad.

But, at least in GP's case, it's not a stdlib problem. Not one solved by Go, anyway.

Re: Migrating from Go to Rust

#432

Post by deagle50 »

tptacek wrote: post #414
deagle50 wrote: post #406

Earlier quoted context omitted.

Or it could be insane to pay the cloud memory costs when you have tools that can write rust for you.

What "cloud memory costs"? Most Rust code is an informally-specified version of the old Python reference-counting GC. That's how you're supposed to write it, with clone() everywhere, and then dropping down to optimize. You can do the same thing with Go in the other direction by writing an allocator. People believe a lot of weird things about these languages.

Why would I roll custom allocation strategies in Go (and then be accountable for supporting them) that affect multiple teams and services when I can have an LLM port to Rust and get dozens of additional benefits?

Re: Migrating from Go to Rust

#433

Post by [deleted] »

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…

[deleted]

Re: Migrating from Go to Rust

#434

Post by sgt »

jorvi wrote: post #270
x-yl wrote: post #244

Earlier quoted context omitted.

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

LLMs generally write poor quality anything. It'll [usually] work, but it'll need massive refactoring to get in a maintainable and efficient state.

I've actually found Opus 4.7 to write decent Django / Python code.

Re: Migrating from Go to Rust

#435

Post by mswphd »

throwaway894345 wrote: post #399
echelon wrote: post #364

Earlier quoted context omitted.

I'm so perplexed by this, because Rust errors are what make the language so amazing. > Now I’m debugging macro expansion errors and spending approximately the same amount of time This never happens once you've learned the language a bit more. Anyhow and thiserror are a cinch. > I realize that this is pretty tedious, manual work, so someone points me to thiserr or similar Claude writes Rust so effectively. It can do a…

I think Claude may be what makes me use Rust successfully. Firstly it’s ability to deal with the tedium and secondly not needing to solicit help from people who tell me my problem is trivial while giving contradictory solutions :) > And the type system will mean that Claude emits better code on average. I’m curious if this is true. I believe that it emits better code than with a dynamically typed language, but as wit…

There's a number of things about rust that help compared to other statically typed languages.

1. the compiler gives very high quality error messages. It helps humans, and also helps LLMs

2. Rust reduces memory management to local reasoning (via the borrow checker). This means that it performs well even as context grows, because checks in one function/module are well-encapsulated to that function/module.

3. Rust can more easily obtain this encapsulation for more general properties than many other statically typed languages. In particular, rust's type system is very strong, so it's easy to take a function `func(x: T)` that relies on some implicit assumption on `x` (say that it is non-zero), and turn it into an explicit requirement. By this, I mean you define `pub struct NonZero(T)`, and provide constructors `pub try_new(t: T) -> Result, _>` that error if the condition doesn't hold. If you additionally only provide public methods on `NonZero` that uphold the invariant, you can lift runtime runtime assertions to the type level. This is both good practice, and helps out LLMs quite a bit.

This is to say that rust makes it quite easy to encapsulate implementation details (both regarding memory management, as well as other details) essentially completely. Sometimes you still have invariants that need care/can't be encapsulated in the type system, but such invariants should be marked `unsafe`, so it can be easier to audit the LLM's output.

Anyway, the "more constraints to balance" is only problematic if all the constraints are inter-dependent. It's definitely possible to get LLMs to generate spaghetti code like this, but the way you fix it is the way you fix similar issues in other languages.

Re: Migrating from Go to Rust

#436

Post by mswphd »

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?

if you have an OOM and want to log why, if your logging allocates it will likely fail as well. You could in principle work around this with enough effort, but "properly" handling OOM is typically much more trouble than its worth.

Re: Migrating from Go to Rust

#437

Post by hombre_fatal »

bottlepalm wrote: post #235
solumunus wrote: post #221

Earlier quoted context omitted.

The benefit is if you lean heavily on types then successful compilation is a massive indicator in the feedback loop. Using stop hooks to ensure successful compilation after every iteration is a game changer. Go also has compilation of course but because the type system is so much more robust in Rust the compilation guarantees so much more about the behaviour of your program. You end up just code reviewing the shape a…

Code compiling is really the lowest bar of code validation, and doesn't say much of anything of the code running correctly. AI will pump out the most convoluted, over engineered, and at the same time sloppy code if you let it - and it will all compile fine.

Well, a good type system like Rust's lets you make impossible states impossible to enter/represent by the system.

Writing code so that impossible states are impossible is one of the hardest parts of software, so a good type system means that the code compiling means that the software is validated to be unable to represent certain states which is a very high bar of validation.

I suppose in your mind you were thinking of more trivial errors like typos, accessing variables that aren't available in scope, and such.

This is the main reason I use Rust over Go these days. The simplicity of Go was great for when I had to hold everything in my head and write everything myself. Rust makes more sense to me in the LLM era where I can offload more modeling/assumptions/invariants to the type system without having to be a Rust veteran.

The pinned invariants in my plan/spec become first-class invariants in the type system. It's great.

Re: Migrating from Go to Rust

#438

Post by skydhash »

cogman10 wrote: post #418
surajrmal wrote: post #391

Earlier quoted context omitted.

The problem is that trust shouldn't be so binary. We should have ways to increase trust without needing to resort to the standard library. There was an effort to do this at some point in rust but the idea was sadly not well received. Maybe it'll end up reviving itself with modern supply chain concerns. The idea is that there could form some groups of well maintained crates that only depend on each other and have a si…

I've harped on this for years, but few devs seem to grasp the concept that less dependencies is better than more. Especially library authors. It's only now that the supply chain problems with npm are becoming beyond obvious that we are seeing devs come around to this notion (leftpad should have been the canary in the coal mine). The javascript ecosystem has corrupted far too many other programming ecosystems. The not…

A lot of libraries should have been gists, blog posts, or stack-overflow answers. When I see a library imports a dependency of a few function related to its domain, I can’t help but wonder why they don’t want to take responsibility for that small snippet of code.

Re: Migrating from Go to Rust

#439

Post by CharlieDigital »

desmaraisp wrote: post #132
OtomotO wrote: post #13

Earlier quoted context omitted.

The stdlib is the place where good ideas go to die. And then you have httplib3 followed by httplib4. In other words: I highly prefer the Rust approach. It doesn't matter a lot whether I rely on the stdlib or another dependency to me. It's a dependency after all. People think just because it's the stdlib it's somehow better quality or better maintained, but these are orthogonal concepts. In the end it depends solely o…

That's an interesting viewpoint, but one I've noticed is less prevalent in other languages. The c# guys at microsoft created an enormous stdlib, and the overwhelming majority of it is pretty good. The outliers being of course older stuff they've never really had time to upgrade. And they don't seem to be afraid to deprecate stuff, every major version brings a couple of minor breaking changes. But it all seems to work…

C# massive standard library and first party libraries means much, much fewer external dependencies and these libraries are managed by a team of paid, professional engineers.

Highly, highly underrated.

Re: Migrating from Go to Rust

#440

Post by chucky_z »

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

We’ve developed incredibly strict and comprehensive clippy rules and found that to drastically improve the quality of the code as the LLM now should pass all clippy checks. You can add a clippy skill as well to attempt to turn “should” into “must.”
Post reply on HN