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

191–200 of 544 posts

Re: Migrating from Go to Rust

#191

Post by what »

awesome_dude wrote: post #157
dwattttt wrote: post #79

Earlier quoted context omitted.

I guess you might have to if you need to use a library someone's written that doesn't implement the standard. Writing primarily applications, I couldn't tell you what error handling frameworks my dependencies are using: I literally don't know, and haven't needed to know in order to display, fail, or succeed. EDIT to add: I use anyhow for this, so I should also add "add context to an error when I fall" to the list of…

Not rust specific, and most certainly not a criticism of you - but I hate when people call a lib that errors, then just bubble that error up. I mean the error is supposed to be tailored to the audience - I guess what you are saying is that you handle the error by saying "I called foo with X, Y, Z, and got this error back" in the logs - which your caller then also does - producing a log message of ERROR: I called Foo…

You’re supposed to bubble errors up to the level that can appropriately deal with them? You don’t need to log them each step of the way.

Re: Migrating from Go to Rust

#192

Post by tptacek »

kelnos wrote: post #189
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 Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". That's not really something I care much about. My beefs with Go are 90% about the syntax of the language itself, and it's weak (compared to Rust) type system. When it comes to a managed runtime, for most tasks, I generally don't care if my language has one or not. For some tasks I do, but there are not many of thos…

That's totally fine. I don't get why people moralize this stuff. Both of these languages are rounding errors compared to the dynamic languages.

Re: Migrating from Go to Rust

#194

Post by kelnos »

tptacek wrote: post #70
iknowstuff wrote: post #15

Earlier quoted context omitted.

Rust does not have three error systems. It has one: the Error trait. io::Error is one of many that implement it (nothing special about it). Errors defined via thiserror also implement it. “Anyhow” just allows you to conveniently say “some Error” if you don’t care to write out an API contract specifying types of errors your function might spit out.

He's not making that up; in practice, you're going to run into and need to make mental space for the idiosyncrasies of multiple error frameworks.

Not sure what you mean by that. If you're consuming the API of a crate that has functions that return errors, you're not really dealing with a "framework", you're just dealing with whatever the `E` is in the `Result`. If that `E` doesn't implement std::error::Error, I'd consider that a deficiency (even a bug) for that crate. (Yes, I know some crates want to support use in `no_std` environments; that's what features are for.)

If I care about the specific variants of error that a function can return, so I can do different things depending on what kind of error occurred, I'll read the docs and match. That's not really a "framework" thing; that's just a basic thing that anyone has to do in any language in order to consume an API. If I need to propagate the error, I'll do so (either directly, or by wrapping it in a variant of my own error type). I don't see how any of this is "framework"-y.

A crate's decision to use thiserror (or not) does not matter to me. If a crate exposes `anyhow::Error`, that's a lazy choice and bad API design, but still "works" and I generally don't need to care about it.

Or is there something else you meant when you said "error frameworks"?

Re: Migrating from Go to Rust

#195

Post by pjmlp »

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.

Rust compilation speed is a matter of tooling, they could have something like OCaml or Haskell interpreters, which so far hasn't been a priority.

Or having Cranelift as default backend.

Re: Migrating from Go to Rust

#196

Post by kelnos »

tptacek wrote: post #192
kelnos wrote: post #189

Earlier quoted context omitted.

> the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". That's not really something I care much about. My beefs with Go are 90% about the syntax of the language itself, and it's weak (compared to Rust) type system. When it comes to a managed runtime, for most tasks, I generally don't care if my language has one or not. For some tasks I do, but there are not many of thos…

That's totally fine. I don't get why people moralize this stuff. Both of these languages are rounding errors compared to the dynamic languages.

I think people do this for every language. It becomes a part of their identity, and then they have to defend it. I used to do that too, long ago, but I don't have the time or energy for it for the most part, and find it boring, so that $LANG-user-as-identity bit of my has fallen by the wayside.

I don't think it's about adoption levels; sure Go and Rust are tiny compared to JS/python/etc. It's emotional, not about who has the most users or who can even plausibly get there.

Re: Migrating from Go to Rust

#197

Post by [deleted] »

pton_xd wrote: post #26
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…

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.

[deleted]

Re: Migrating from Go to Rust

#198

Post by lofties »

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.

Reading the code? Who has the time.

Aah, I am sure the chickens of vibe coded origin, will never come to roost.

Re: Migrating from Go to Rust

#199

Post by dwattttt »

awesome_dude wrote: post #157
dwattttt wrote: post #79

Earlier quoted context omitted.

I guess you might have to if you need to use a library someone's written that doesn't implement the standard. Writing primarily applications, I couldn't tell you what error handling frameworks my dependencies are using: I literally don't know, and haven't needed to know in order to display, fail, or succeed. EDIT to add: I use anyhow for this, so I should also add "add context to an error when I fall" to the list of…

Not rust specific, and most certainly not a criticism of you - but I hate when people call a lib that errors, then just bubble that error up. I mean the error is supposed to be tailored to the audience - I guess what you are saying is that you handle the error by saying "I called foo with X, Y, Z, and got this error back" in the logs - which your caller then also does - producing a log message of ERROR: I called Foo…

I have tried to figure out some kind of unification between "collecting error state in a function", "logging error state", and "return error state to a parent".

I haven't found any satisfying solution to it all; collecting information for logging vs information that a caller would want... I've been meaning to investigate tracing_error to see if it brings it all together.

Re: Migrating from Go to Rust

#200

Post by nihsett »

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 work on top of maybe need that level of control over memory. It doesn't make any sense to me to sign up for that complexity unless you really really need it.

Post reply on HN