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

521–530 of 544 posts

Re: Migrating from Go to Rust

#521

Post by throwaway894345 »

echelon wrote: post #422
throwaway894345 wrote: post #399

Earlier quoted context omitted.

I think Claude may be what makes me use Rust successfully. Firstly it’s ability to deal with the tedium and secondly not needing to solicit help from people who tell me my problem is trivial while giving contradictory solutions :) > And the type system will mean that Claude emits better code on average. I’m curious if this is true. I believe that it emits better code than with a dynamically typed language, but as wit…

> Firstly it’s ability to deal with the tedium and secondly not needing to solicit help from people who tell me my problem is trivial while giving contradictory solutions :) I'm so sorry for this btw. The problems are trivial once you've used Rust for n hours, for some value n. It's just that these folks forgot the learning and headache they went through. You're going to build that same recognition and familiarity us…

> I'm so sorry for this btw.

All good. It happens in every community, but it seems like Rust has more of these problems where there are N ways to do something and none of them are obvious. Reminds me of Python where everyone swears they have a package manager that will fix all previous problems and then you invest a bunch of time into their suggestion only to find that it introduces half a dozen new glaring problems (e.g., pipenv taking 30 minutes to resolve a lock file for a relatively small project).

> The problems are trivial once you've used Rust for n hours, for some value n.

Heh, I've been taking a real stab at Rust every year since 2014. `n` can be a pretty large value! I'm optimistic that Claude and friends will help me get there though.

> Being forced to emit an Option or Result and then having to actually use syntax to get at the goods forces the code to deal with errors the appropriate way, clearly, idiomatically, and typically in a good flow that is amenable to readability and easy refactoring. Other languages without Option, Result, and sum types baked into the language so fundamentally do not have this advantage.

Honestly I use Go as my daily driver these days and while I wish it had sum types for error handling, it's really not a problem. It's more aesthetics than anything, and LLMs do just fine with managing errors in Go. There may be other advantages for LLMs with respect to Rust's rigorous type system, but I could easily see it going the other way as well (additional constraints for the LLM to focus on, taking more of its context budget that could go to the fundamental product constraints). I really don't know what the right answer is here--I suppose time will tell.

Re: Migrating from Go to Rust

#522

Post by tracker1 »

apatheticonion wrote: post #346
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 use Rust for web services all the time. It's a dream compared to Go (which I wrote professionally for years). At this point, I can't imagine a scenario not to use Rust for writing a web API.

Dunno... I really like FastEndpoints in C# a lot as well as Hono in JS/TS environments. That said, I do like Axum in Rust. All for varying reasons though.

Re: Migrating from Go to Rust

#523

Post by ahknight »

bjoli wrote: post #499
gritzko wrote: post #420

Earlier quoted context omitted.

That is interesting. I make LLMs write C with the general hope that a simpler language they can manage well. That is not entirely true, though. They reason about C fluently indeed. The problem is, Claude pumps lots of bad C into the codebase if left unattended for 5 min. So, I need some clean-up passes afterwards to get to some acceptable quality level (both by LLMs and my own eyes). At which point, Claude sees the p…

> if left unattended for 5 min. Is THAT how people use AI? I thought _I_ was vibe coding by telling it to write one function at a time and making sure I understand every line it outputs.

"Vibe coding" is a term that means "Prompt the LLM with a request for a project and wait for it to finish". If you're reading and understanding anything it made, that's not vibe coding, that's agentic development.

Re: Migrating from Go to Rust

#524

Post by awesome_dude »

andrewflnr wrote: post #519
awesome_dude wrote: post #511

Earlier quoted context omitted.

> what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them. Zero. The required number of problems needs to be zero - hence my OP > I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why? The bigger question is - why doesn't 3.9 compile and run 3.8 Further, in what world is targeti…

> Zero. The required number of problems needs to be zero - hence my OP This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.

I explictly say that NO dependency management is without problems, AND call out Go's attempts in my OP.

You came barrelling because your favorite tool is mentioned, and then, when you realize that it deserves the criticism you try and play that?

Maybe, just maybe, take an objective look at the real problem (dependency management) and recognise that, as stated, nobody has solved it.

Re: Migrating from Go to Rust

#525

Post by cdud3 »

afdbcreid wrote: post #460
cdud3 wrote: post #283

Earlier quoted context omitted.

I found it's the opposite. Thanks to LLM's whole classes of problems otherwise solved by using Rust are gone. It's now more important that the generated code is easy to read.

Relative to Go? I'm pretty sure your Go code won't be faster if you used LLMs. If you need that, Rust is still preferred. Relative to C/C++? That'll be very interesting. Do you have some evidence that LLMs can create memory-safe code in C/C++? It'll be truly amazing if true, but given that they apparently struggle to create/maintain big codebases in already-memory-safe languages I seriously doubt it.

Yes, generated C++ is memory-safe. Also there is much more C/C++ code out there LLM's got trained on showing in the quality.

Re: Migrating from Go to Rust

#526

Post by dwattttt »

63stack wrote: post #512
wtetzner wrote: post #472

Earlier quoted context omitted.

This sounds disingenuous. They explained why the language doesn't force stack traces on all errors, and then explained how to get them if you want them.

I see a very opinionated explanation, not a "this is why the language does not" explanation. >Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues. This is a personal opinion, not something you can declare as the objective tr…

I'm curious, what's the value of a stack trace of another person's library functions? As mentioned, you can get a stack trace that includes all of your code, that's what was offered to you.

The only thing a library gathering a stack trace instead of you gives you is that it includes traces through code you didn't write & ostensibly aren't responsible for. If you're going to go to the effort of tracing through a dependencies code, you might as well add the stack trace yourself; it's a single line of code from the standard library to collect it, std::backtrace::Backtrace::capture().

EDIT: capture will only actually grab a trace when env vars say it should, you can use force_capture to ignore those. To get to why this isn't the default for errors you're asking for, here's a line from their documentation:

> Capturing a backtrace can be both memory intensive and slow

Re: Migrating from Go to Rust

#527

Post by wtetzner »

IshKebab wrote: post #507
wtetzner wrote: post #466

Earlier quoted context omitted.

Except anyhow is compatible in that direction. io::Error and thiserror types will automatically convert to anyhow errors.

In my experience it's not quite as automatic as you'd hope. I always often to throw in stuff like `.map_err(Into::into)` or `Ok(foo?)` to convert the errors. Not the end of the world but I do think defending the proliferation of error types in typical Rust projects is copium.

Yes, `?` automatically does `.into()`.

There are plenty of reasons you can complain about Rust's error handling, but "proliferation of error types" feels like a misunderstanding of how Rust error handling works in the first place.

Re: Migrating from Go to Rust

#528

Post by andrewflnr »

awesome_dude wrote: post #524
andrewflnr wrote: post #519

Earlier quoted context omitted.

> Zero. The required number of problems needs to be zero - hence my OP This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.

I explictly say that NO dependency management is without problems, AND call out Go's attempts in my OP. You came barrelling because your favorite tool is mentioned, and then, when you realize that it deserves the criticism you try and play that? Maybe, just maybe, take an objective look at the real problem (dependency management) and recognise that, as stated, nobody has solved it.

I was trying to be sympathetic and acknowledge virtualenv's potential flaws, actually, even though I haven't personally encountered them, but I guess that was a waste of time.

Re: Migrating from Go to Rust

#529

Post by dxdm »

andrewflnr wrote: post #528
awesome_dude wrote: post #524

Earlier quoted context omitted.

I explictly say that NO dependency management is without problems, AND call out Go's attempts in my OP. You came barrelling because your favorite tool is mentioned, and then, when you realize that it deserves the criticism you try and play that? Maybe, just maybe, take an objective look at the real problem (dependency management) and recognise that, as stated, nobody has solved it.

I was trying to be sympathetic and acknowledge virtualenv's potential flaws, actually, even though I haven't personally encountered them, but I guess that was a waste of time.

Only if you let it. I learned something from the response to my question.

Folks, take a step back, both of you. It's just software.

Re: Migrating from Go to Rust

#530

Post by iknowstuff »

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.

I’m sorry but this is simply incorrect and I think stems from insufficient understanding of best practices and/or how the Error trait composes, as the other replies alluded to. There’s a lot of reading material on the subject but unfortunately I can’t recommend anything off the top of my head
Post reply on HN