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

171–180 of 544 posts

Re: Migrating from Go to Rust

#171

Post by ventana »

awesome_dude wrote: post #55
LtWorf wrote: post #39

Earlier quoted context omitted.

Praising go for how it handles errors, when it's even worse than C where the compiler at least warns you if you're ignoring return values of calls. That's a new one.

Linters are available to catch you before you compile - with Go Generally speaking there has to be a mechanism for optional handling of return values, in Go you can ignore everything (ew), you can use placeholders `_`, or you can explicitly handle things - my preference. If you say "Well in C you have to handle the returns - I am not across C enough to comment, but I will ask you - Does C actually force you, or does…

C, as a language, cannot bother less about you using or not using the return values, checking them, discarding them, or using them to index an array without any bounds checking. Various linters and compilers may have their opinions, expressed as warnings, but at the end of the day it's completely up to you as a developer.

Re: Migrating from Go to Rust

#172

Post by euroderf »

zjy71055 wrote: post #143

I was a Go engineer for years and have shipped a lot of Go. I never properly learned Rust. Over the past year I've been using AI to write small Rust tools for myself — I barely read the code, and honestly it just works. But for serious projects I expect to maintain long-term, I still pick Go. Today I want code I can actually own and reason about myself. Give it a year or two and I probably won't be writing code by ha…

> But for serious projects I expect to maintain long-term, I still pick Go.

Maintenance is a big win for Go imho - that you can go to code you wrote a year or more ago - and jump right back into it, with little-to-no re-learning curve. The syntax is not providing cover for complexity bombs, and the tools keep the workflow simple and quick.

How is it with Rust ? Does one's own old code remain maintainable ?

Re: Migrating from Go to Rust

#173

Post by euroderf »

0xfurai wrote: post #35

The "when to enforce it" framing is what sticks with me. Go and Rust agree on safety, concurrency, simple deployment, but Go says "catch it in review" and Rust says "catch it before it compiles." The right answer depends entirely on how expensive a production incident is for you vs. how expensive slower iteration is.

And TLA+ and Lean say "catch it before you write any code".

Re: Migrating from Go to Rust

#174

Post by gitaarik »

OtomotO wrote: post #44
amarant wrote: post #27

Earlier quoted context omitted.

As someone with a background of consulting in the Stockholm based gaming industry for the last decade+, I have to respectfully disagree. Nearly everyone I know is very much on the hype train. And for good reason too! The capabilities are undeniable!

As is the hype. You know, shovels are useful, they are just more useful to the shovel manufacturer than the gold diggers. But in the end it's a cool tool that made it way easier to dig holes and tend to your garden!

So you're not using a shovel to maintain your garden?!

Re: Migrating from Go to Rust

#175

Post by gitaarik »

amazingamazing wrote: post #19
johnfn wrote: post #18

Earlier quoted context omitted.

Can you explain a bit about why token costs would favor Go and not Rust?

Go is more verbose, but Rust have more complex syntax which in practice require more tokens. The big thing though is because builds are slower, you will end up waiting longer as tests are modified, rebuilt and run. This difference piles up fast.

Waiting longer for tests / builds doesn't have effect on token usage..

Rust's compile time is longer because the compiler does much more. And therefore the binaries are often smaller, start and run faster than Go

Re: Migrating from Go to Rust

#176

Post by gitaarik »

amazingamazing wrote: post #32
crabmusket wrote: post #29

Earlier quoted context omitted.

> spending more time and tokens waiting around Can you clarify how you're spending tokens on waiting? My understanding is that the LLM isn't actually necessarily doing anything while a build runs. The whole process end to end may take longer for sure (ignoring things like the compiler catching more errors, that's really hard to factor in) but how does that correlate to more tokens?

> The whole process end to end may take longer for sure (ignoring things like the compiler catching more errors, that's really hard to factor in) but how does that correlate to more tokens? This. rust emits more information both in its output and the syntax itself more complicated requires more tokens.

Your agent doesn't know how to use grep?

Re: Migrating from Go to Rust

#177

Post by marcus_holmes »

st3fan wrote: post #153
marcus_holmes wrote: post #138

Earlier quoted context omitted.

We tend not to use ORMs, because they're evil. There are various libraries people use for auth, etc. But rolling your own isn't hard - Go has (e.g.) bcrypt in the standard library, so most of the heavy lifting is already done, you can write a solid auth implementation in Generally Go prefers libraries to frameworks. Wrap the hard bits up into a library that can then be used widely in any implementation, rather than r…

please don’t generalize. there is no “we” .. “we” are all different and i can tell you from experience that there are also many people and teams who use go and prefer ORMs and frameworks and do not build everything from scratch …

true, but there does tend to be a consensus (or has been) in the Go community around a lot of this stuff.

Re: Migrating from Go to Rust

#178

Post by mountainriver »

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 perspective

Re: Migrating from Go to Rust

#179

Post by loeg »

fweimer wrote: post #61
lionkor wrote: post #16

Earlier quoted context omitted.

> Rust lacks a uniform error type Rust has practically one error, it's the Error trait. The things you've listed are some common ways to use it, but you're entirely fine with just Box (which is basically what anyhow::Error is) and similar.

Surely you need an alternative to Box for reporting memory allocation failures?!

Anything other than panic/abort on allocation failure is outside the scope of the vast majority of programs, including anything using the standard library in Rust. I wouldn't worry about Box.

Re: Migrating from Go to Rust

#180

Post by wyager »

fweimer wrote: post #61
lionkor wrote: post #16

Earlier quoted context omitted.

> Rust lacks a uniform error type Rust has practically one error, it's the Error trait. The things you've listed are some common ways to use it, but you're entirely fine with just Box (which is basically what anyhow::Error is) and similar.

Surely you need an alternative to Box for reporting memory allocation failures?!

You're already writing Rust in a very different style if you're writing the type of code that gracefully handles allocation failure. It's to Rust's immense credit that this type of coding is actually fairly well-supported (unlike in Go), but you're already a bit off the beaten path for stuff like error handling.
Post reply on HN