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

51–60 of 544 posts

Re: Migrating from Go to Rust

#51

Post by fpoling »

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…

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.

Re: Migrating from Go to Rust

#52

Post by corndoge »

awesome_dude wrote: post #33
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…

Package management is the bane of nearly every language/technology Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?) For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine) There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseud…

Nix solved it. Languages could choose to adopt Nix as their packaging system.

Re: Migrating from Go to Rust

#53

Post by kajman »

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.

The cost of verbose compiler output surely cannot compare to the cost of shipping bugs that would've been caught at build time.

Re: Migrating from Go to Rust

#54

Post by J_Shelby_J »

logicchains wrote: post #11
gertlabs wrote: post #3

I liked Rust before running a benchmark, but the gap between how effectively most LLMs write in Rust vs Go was still surprisingly large to me (especially in agentic harnesses where they can fix the initial environment issues). I've become a pretty big Rust evangelist after seeing that. We've had a lot of success writing batch processing tools in Rust to be called by our existing codebase, but haven't attempted a full…

The weakness of Rust WRT LLMs is compilation times. LLMs code faster and hence spend relatively more time waiting for compilation than humans do, so on reasonably sized projects (e.g. 100k+ lines) Rust's ~10x slower compilation starts showing up as a bottleneck. If you're writing some critical infrastructure it makes sense to pay that cost, but if you're writing some internal service that's not publicly exposed to th…

10x slower is like an extra second, if that, for compilation times for the sizes of changes an agent like codex makes.

Re: Migrating from Go to Rust

#55

Post by awesome_dude »

LtWorf wrote: post #39
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…

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 it allow you to say "ok I will put some variables in to catch the returns, but I will never actually use those variables" - because that's very much the same as Go with the placeholder approach

edit: I am told the following is possible in C

trySomething(); // Assumes that the author of trySomething has not annotated the function as a `nodiscard`

(void)trySomething(); // Casts the return(s) to void, telling the compiler to ignore the non-handling

int dummy = trySomething(); // assign to a variable that's never used again

I welcome correction

Re: Migrating from Go to Rust

#56

Post by fatty_patty89 »

repelsteeltje wrote: post #28
fatty_patty89 wrote: post #20

Earlier quoted context omitted.

wails, there's wails3-alpha which some people said is even better than tauri

Thanks. Is wails a Go stdlib component, as GP implied or is it third party?

tauri isn't stdlib and neither is wails

Re: Migrating from Go to Rust

#57

Post by amazingamazing »

kajman wrote: post #53
amazingamazing wrote: post #32

Earlier quoted context omitted.

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

The cost of verbose compiler output surely cannot compare to the cost of shipping bugs that would've been caught at build time.

Indeed, but is it the case that all bugs you have are those in which would be caught by the compiler? It’s not like rust code inherently is bug free.

Re: Migrating from Go to Rust

#58

Post by the__alchemist »

amazingamazing wrote: post #7

Rust is great. However in an agentic world go will win. Look no further than incremental build times. This, combined with high token costs mean that for a given application it simply will cost more to to write it in Rust than Go. This can easily be justified for many usecases, but for your vanilla crud app, do you really need Rust? Per the article, you are getting 20-50% better more performance with Rust. Not worth i…

> However in an agentic world go will win

This is Silicon Valley fantasy.

Re: Migrating from Go to Rust

#59

Post by J_Shelby_J »

gertlabs wrote: post #3

I liked Rust before running a benchmark, but the gap between how effectively most LLMs write in Rust vs Go was still surprisingly large to me (especially in agentic harnesses where they can fix the initial environment issues). I've become a pretty big Rust evangelist after seeing that. We've had a lot of success writing batch processing tools in Rust to be called by our existing codebase, but haven't attempted a full…

The detailed compiler errors and strong type system makes the change -> compile -> change loop simple for agents to handle. Rust provides very strong rails it forces users on to. Codex always manages to get something to compile.

The downside is that maybe it should fail sometimes when an idiomatic approach isn’t viable… instead it will implement something stupid that compiles and meets the request.

Re: Migrating from Go to Rust

#60

Post by [deleted] »

OtomotO wrote: post #13
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…

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…

[deleted]
Post reply on HN