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

211–220 of 544 posts

Re: Migrating from Go to Rust

#211

Post by kalaksi »

nihsett wrote: post #200
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…

Exactly. 95% of programmers are application programmers - they ship software used by regular users. I think it's insane to use a non-GC language for most of those cases. Manual memory management is mentally taxing and it's easy to make catastrophic mistakes. The marginal benefit from it is just not worth it unless you're making games or a trading system. 5% who write tools or other "infra" layer for the other 95% to…

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.

Re: Migrating from Go to Rust

#212

Post by worthless-trash »

uh_uh wrote: post #117
fpoling wrote: post #51

Earlier quoted context omitted.

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.

What kind of apps are you writing where GC spikes matter?

trading, networking, gaming, ai, realtime, almost anything with hard response requirements.

Re: Migrating from Go to Rust

#213

Post by samat »

samat wrote: post #210
nemo1618 wrote: post #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-gen…

And many others. I felt it too And it’s a good contrast with ‘just fcking use Go’ article he linked. Go article is much more human. I love that and would choose a human centered language and human centered culture over LLM-centered everything every time I guess I am just old

And tables with comparisons! Nobody makes a table by hand if it’s not packed with value. Tables in this article are not

Re: Migrating from Go to Rust

#214

Post by Certhas »

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.

It's the same logic for human and for AI code: In Rust the compiler catches many bugs so you don't have to.

If the LLM gives you safe code you know there are entire classes of things you don't have to review for.

That said, I agree with you. My experience is that LLMs are great if you are highly competent in the domain in which you let them work. And it's probably easier to be competent in Go than in Rust.

Re: Migrating from Go to Rust

#215

Post by tptacek »

kalaksi wrote: post #211
nihsett wrote: post #200

Earlier quoted context omitted.

Exactly. 95% of programmers are application programmers - they ship software used by regular users. I think it's insane to use a non-GC language for most of those cases. Manual memory management is mentally taxing and it's easy to make catastrophic mistakes. The marginal benefit from it is just not worth it unless you're making games or a trading system. 5% who write tools or other "infra" layer for the other 95% to…

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.

Re: Migrating from Go to Rust

#216

Post by OtomotO »

gitaarik wrote: post #174
OtomotO wrote: post #44

Earlier quoted context omitted.

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

I am, but I am no part of any shovel cult.

Re: Migrating from Go to Rust

#217

Post by tptacek »

LtWorf wrote: post #208
lanstin wrote: post #155

Earlier quoted context omitted.

I like vibe coding but I am sceptical that a vibe coded runtime in Rust would be as awesome as the Go runtime which is written with deep expertise of Unix software and threading and many low level details that are subtle and do depend on global properties of the code to work flawlessly. It makes sense you can crank out Rust with an LLM if you know what you are doing, but if you want a GC type thing or preemptive sche…

> the Go runtime which is written with deep expertise of Unix software Go has no mmap(), import a 3rd party dependency for that and you'll get a segfault the very second you do a mistake. Python has an mmap module which will catch many memory errors and present them as exception rather than causing a CVE.

I don't agree with the parent comment, but mmap is exposed (low-level) in the standard library and there's a high-level wrapper in x/exp. You need to be careful with mmap no matter where you're using it.

What Go mmap CVE were you thinking of?

Re: Migrating from Go to Rust

#218

Post by swiftcoder »

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…

> Rust has three main error systems (io::Error, thiserror, and anyhow), which is a pain when you have to pass them upward through a chain of calls

anyhow explicitly isn't designed for what you are trying to do here. It's designed to be the last link in the chain (and complementary to thiserror, not in competition). If you are using anyhow any deeper than your top-level binary crate, you are likely to be in for an unpleasant time.

Re: Migrating from Go to Rust

#219

Post by pscanf »

tkiolp4 wrote: post #81
nemo1618 wrote: post #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-gen…

I think the whole post is AI generated. The author could have given a draft as input and perhaps edited the output in a few places. Take this paragraph as example: > Go got generics in 1.18, and they’re useful, but the implementation has constraints (no methods with type parameters, GC shape stenciling, occasional surprising performance characteristics). Rust generics monomorphize, each instantiation produces special…

> Every sentence says something. Every sentence is important and holds its weight. [...] Also, it makes the post harder (and more boring) to read.

I actually prefer that style of writing! (When it's not AI-generated ofc.) And I also try to use it in my technical blog posts. I usually re-read my drafts asking myself: "Does the reader actually care about this? Is this sentence adding something or is it just fluff?"

And actually I feel like AI text usually produces more fluff, or anyway I notice it more, but I see how it can make the result "robotic and boring".

Post reply on HN