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

221–230 of 544 posts

Re: Migrating from Go to Rust

#221

Post by solumunus »

bottlepalm wrote: post #182
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…

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.

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 and flow of data.

Re: Migrating from Go to Rust

#223

Post by sheept »

bottlepalm wrote: post #182
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…

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.

In my experience, Rust is only mildly unpleasant to review, if only because the GitHub PR review interface is not an IDE. It can be hard to tell why .as_ref()s and whatnot had to be used without being able to hover over a variable to see its type. This is probably because of the language's preference for type inference, though personally I would rather that than having to skim over explicit types.

Compared to Rust, Go as a language requires a lot more effort to review. You have to be on the lookout for basic gotchas like not checking if a pointer is nil, placing `defer` in the wrong place, using a result when err isn't nil, and so on. Plus, diffs are messier because unused variables are a compilation error, and _, err := can change into _, err = solely due to new lines above.

Re: Migrating from Go to Rust

#225

Post by rixed »

throwaway894345 wrote: post #170
rixed wrote: post #161

Earlier quoted context omitted.

[flagged]

I know you’re trying to snark, but I’m clearly thinking for myself—that ought to be evident from the first sentence of my post. :)

Apologies for the phrasing, I should have written "form your own judgment"

Re: Migrating from Go to Rust

#226

Post by kaashif »

lofties wrote: post #198
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.

Reading the code? Who has the time. Aah, I am sure the chickens of vibe coded origin, will never come to roost.

Time isn't the constraint here, but ability. Someone complaining about how hard Rust is to write is probably not capable of reviewing Rust code very well.

The usual reaction or opinion from e.g. good C++ programmers switching to Rust is that the added guardrails and expressivity are great and make things easier.

Re: Migrating from Go to Rust

#227

Post by LoganDark »

kelnos wrote: post #187
LoganDark wrote: post #95

Earlier quoted context omitted.

thiserror and anyhow are just std::error with extra steps. Note that io::error is just a specific std::error. The entire point in Rust is that you wrap Error impls with other Error impls, or translate one impl into another using a match. I've found this is far more flexible and verifiable than most other languages, because if you craft your error types with enough rigor, you can basically have a complete semantic bac…

thiserror and anyhow are std::error::Error with fewer steps.

They're external crates that either generate Error implementations (thiserror) or act as dynamic wrappers implementing Error (anyhow), so they're more than a simple hand-written implementation. But the developer experience of pulling thiserror or anyhow off the shelf can certainly be more convenient than the hand-written implementation, sure.

Re: Migrating from Go to Rust

#228

Post by BlackFly »

tptacek wrote: post #215
kalaksi wrote: post #211

Earlier quoted context omitted.

Maybe I'm misunderstanding something but non-GC language doesn't mean you have to do memory management manually? I mean, for example, in Rust (or modern C++), it's basically automatic. There is no mental tax or catastrophic mistakes as far as I know.

Ok. https://rust-unofficial.github.io/too-many-lists/ I'm not saying Rust is worse than Go. It obviously isn't. But this argument that Rust's memory management isn't more cognitively demanding than Go's memory management --- that isn't true.

Certainly you pay a price for lifetimes but you buy compile time race condition detection via the borrow checker's aliasing-xor-mutability enforcement. So all that is happening is the complexity of concurrency is being made explicit and therefore easier to reason about. Many applications can be architected in a way that wouldn't ever trigger a race, so for people working on that it isn't something they would need to reason about and they can call it unneeded complexity. This is the simpler vs. simplistic distinction also made in the article. If you can be simplistic, garbage collection is less cognitively demanding, but if you are designing race free algorithms with shared memory then rust will be. I do believe more developers and applications live in the former.

The better example actually comes from the article: returning a struct and an iterator over that struct isn't possible in rust. Heck, initializing a struct to return an iterator might lead to issues. Most people will encounter this before needing a linked list and the lesson it teaches will help out with the linked list.

Re: Migrating from Go to Rust

#229

Post by kune »

netheril96 wrote: post #162
ted_dunning wrote: post #154

Earlier quoted context omitted.

The guardrails are channels. If you have a mutex on a structure, linters such as are packaged into Goland will catch oversights quite effectively. If you are using fancier concurrency structures, you should consider channels instead.

Channels are not for everything. Plenty of mutex cases cannot be rewritten as channels, or will be very unwieldy so. In fact, every large Go project I have seen uses mutex here or there.

Theoretically you can use channels to simulate a mutex, but I agree with you there are use cases where a mutex makes more sense. They are even used in the standard library, for instance to implement sync.Once.

But generally I would agree that if you need to code parallel execution, channels are a good way to do it, because you can avoid race conditions if you share data only over channels. The biggest problem is that a lot of people don't understand, that channels with a buffer larger than 1 are a sign of problems in the architecture.

There is a type of parallel programming with workers for specific functions, that always leads to performance issues. The problem is you need to right-guess the distribution of work, when you have to define the amount of workers for a specific function. At least one go routine for one request is a much better approach than function-specific workers.

Re: Migrating from Go to Rust

#230

Post by PaulRobinson »

tempest_ wrote: post #93
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…

The use of LLMs has caused Rust usage to explode. If youre not writing the code yourself and vibing away which I think most people generally are despite the disdain around here then why would you not choose the "more performant language" (I know that isnt necessarily reality but it is a common perception). Go's managed runtime is less valuable when the LLM is perfectly happy to slap a bunch of stuff together for you…

By that reasoning, we should all be vibing away C code. It's the most performant and efficient language out there, there's a ton of code out there the LLMs were trained on, and the complex logic of memory management is abstracted away by the LLM so you don't need to think about it.

Most people are not doing that though. There's probably a good reason, and it applies to other languages too.

Post reply on HN