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

251–260 of 544 posts

Re: Migrating from Go to Rust

#251

Post by p2detar »

fpoling wrote: post #51
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.

Go has the Green Tea GC since 1.25. It’s no longer simplistic and quite well engineered. The AVX-512 support was especially interesting to me.

https://go.dev/blog/greenteagc

Re: Migrating from Go to Rust

#252

Post by robocat »

bottlepalm wrote: post #236
Certhas wrote: post #214

Earlier quoted context omitted.

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.

Safe? No compiler is going to catch badly designed code, or intentionally backdoored code. Memory leaks as well. Compilers are the ground floor of validation and the least of your problems with AI generated code.

A mythical compiler might catch unsafe code

Re: Migrating from Go to Rust

#253

Post by internet101010 »

physicsguy wrote: post #231
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.

> Rust still rely on many C and C++ libraries Yes but Rust has a lot more availability of libraries to do stuff as a result. Want to do anything ML or scientific? You at least have a route in Rust where you don’t with Go.

Has there been a lot of progress with ML in Rust? I don't really keep up with it because it seems like every crate ends up getting abandoned and I just gave up caring.

Re: Migrating from Go to Rust

#254

Post by p2detar »

marcus_holmes wrote: post #138
the__alchemist wrote: post #135

Earlier quoted context omitted.

Interesting! Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? Or each person and org has their own toolkit they use?

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…

I second that no-ORM statement. I even follow that in Java. Object mapping is fine, but I’ll write my own SQL, rather than debug obscure (to me) HQL queries.

Re: Migrating from Go to Rust

#255

Post by LtWorf »

ventana wrote: post #171
awesome_dude wrote: post #55

Earlier quoted context omitted.

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.

Same as in go, a language designed several decades later.

Re: Migrating from Go to Rust

#256

Post by lionkor »

BobbyJo wrote: post #25
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.

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

Please go write C++ and then come back to us

Re: Migrating from Go to Rust

#257

Post by [deleted] »

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…

[deleted]

Re: Migrating from Go to Rust

#258

Post by ruicraveiro »

mountainriver wrote: post #178
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…

Go was never about being easy to write (thought it is), but it was always about being easy to read and it is, by far, the easiest language to read that I've ever used (and throughout the decades, I went through Basic, Pascal, C, Java, JavaScript, C#, TypeScript, Ruby and Python). That becomes even more important if you are not writing the code yourself...

Re: Migrating from Go to Rust

#259

Post by maxloh »

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 don't know about the author's background, but there is now a generation of non-native programmers who learned to write English by using LLMs for corrections (yeah including this comment).

The irony is that studies show LLM detectors have a much higher false-positive rate for non-native speakers [1]. If most of what you read stems from LLMs, you end up writing like an LLM.

[1]: https://hai.stanford.edu/news/ai-detectors-biased-against-no...

Re: Migrating from Go to Rust

#260

Post by dwattttt »

dnautics wrote: post #163
sheept wrote: post #156

Earlier quoted context omitted.

A Rust library likely wouldn't be returning an opaque Box to begin with. Errors are part of a library's API—it's what allows consumers to handle them—so you'd define an enum of possible errors your library could produce and return that, which would be stored on the stack.

What about the data in the error payload?

I think this is a clash of terminology: a Rust enum isn't an integer with pretensions of an identity.

You'd describe it as a tagged union in some languages. So when you say you'd return an error with extra information, what that information is is associated with the specific variant of the enum.

Using yuriks AllocError as an example, if the error is SizeTooLarge, it has the size field. Other errors may have no additional data, others may have different data.

When you return an error from your allocating function, it's a known size, the size of the largest enum variant + the discriminant (tag).

Post reply on HN