Live data from Hacker News

Migrating from Go to Rust

corrode.dev

21–30 of 544 posts

Re: Migrating from Go to Rust

#21
LLM writing tells are getting more subtle, but they still jump off the page for me, in particular the word "genuine:"

   "This is the area where Go genuinely shines, and it’s worth being precise about why"
   "the lack of GC pauses is a genuine selling point"
   "Humans are genuinely bad at reasoning about memory"
   "There are cases where the borrow checker is genuinely too strict"
tbc I don't think the article was fully AI-generated, just AI-assisted. If so, the author did a genuinely good job of it! No one else is commenting on it, so clearly it didn't detract much from the substance. It's just weird that this is becoming increasingly common, and increasingly hard to detect.

Re: Migrating from Go to Rust

#22

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…

Because the agentic world involves the generation of so much code that gets harder to review, I would think the compile-time guarantees of Rust would make it a better option.

Re: Migrating from Go to Rust

#23

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…

Why is it worse to import a number of other packages that provide exactly the functionality you need, than to have a large standard library that provides some but not all of the functionality you need, requiring you to still use some large dependencies?

Re: Migrating from Go to Rust

#24

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…

Because the agentic world involves the generation of so much code that gets harder to review, I would think the compile-time guarantees of Rust would make it a better option.

This is true if the token budget and time are not taken into account. In practice though, waiting minutes instead of seconds per build multiplied by prompt and again by change adds up very fast.

Re: Migrating from Go to Rust

#25
post #16
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 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.

Having many semantic options for error usage is functionally the same as having many error types, except worse.

Re: Migrating from Go to Rust

#26

LLM writing tells are getting more subtle, but they still jump off the page for me, in particular the word "genuine:" "This is the area where Go genuinely shines, and it’s worth being precise about why" "the lack of GC pauses is a genuine selling point" "Humans are genuinely bad at reasoning about memory" "There are cases where the borrow checker is genuinely too strict" tbc I don't think the article was fully AI-gen…

This is completely off topic now but, "it's worth being precise about ..." is a much stronger AI-ism than the usage of the word genuine.

Re: Migrating from Go to Rust

#27
post #17

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…

It's a good thing then, that the AI hype is dying outside of ycombinator, the silicon valley and the US

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!

Re: Migrating from Go to Rust

#28

Earlier quoted context omitted.

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?

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?

Re: Migrating from Go to Rust

#29

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…

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

Re: Migrating from Go to Rust

#30

Earlier quoted context omitted.

Because the agentic world involves the generation of so much code that gets harder to review, I would think the compile-time guarantees of Rust would make it a better option.

This is true if the token budget and time are not taken into account. In practice though, waiting minutes instead of seconds per build multiplied by prompt and again by change adds up very fast.

When everyone is armed with Mythos-like hacking ability, it's hard for me to imagine people wouldn't make the tradeoff of security over price.
Post reply on HN