Live data from Hacker News

Migrating from Go to Rust

corrode.dev

341–350 of 544 posts

Re: Migrating from Go to Rust

#341
post #297

Earlier quoted context omitted.

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.

You seem to imply that it doesn’t have any cost. It does. You have to make decisions and, in the case of C++: sometimes you have to deal with a lot of really ugly code to make it “automatic”. And if you really have to count bytes and carefully manage stack sizes because you are writing code for a constrained device, you have to pay even more attention than you would in C. GC’ed languages have memory related challenge…

Yeah, I shouldn't have mentioned C++, it was a bad example.

Re: Migrating from Go to Rust

#342
What about AI assisted migration?

There was a signal to assist c++ to plain and simple C AI mass migration.

Removing any languages with ultra-complex syntax towards simple and plain C is always a good thing.

Re: Migrating from Go to Rust

#343

Earlier quoted context omitted.

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…

By that reasoning, we should all be vibing away C code. It's the most performant and efficient language out there, there's a ton of code out there the LLMs were trained on, and the complex logic of memory management is abstracted away by the LLM so you don't need to think about it. Most people are not doing that though. There's probably a good reason, and it applies to other languages too.

There is a good chance that your vibe coded C program segfaults immediately upon running and contains lots of subtle logic errors, all of which requires many iterations (finding issues at runtime) before you program runs as expected.

With Rust, you'll likely get many compilation errors, but if your syntax is correct, compilation errors will be few, and your code will almost certainly just work.

Re: Migrating from Go to Rust

#345

I would think that you might have a better time going from go to zig. You would have to provide a pattern for implementing the interface model go uses.

What are the benefits of moving from Go to Zig?

It seems like you lose a lot (automatic memory safety, simple language, easy concurrency) and gain very little.

Re: Migrating from Go to Rust

#346
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.

Re: Migrating from Go to Rust

#347
post #244

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…

In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust. They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .…

You gotta know how to write Rust (and general software arch) first. LLMs + Rust have been great for me.

"Write an SQL Repository with this interface"

Sweet - no need for SQLc or an ORM

Re: Migrating from Go to Rust

#348

Earlier quoted context omitted.

The benefit is if you lean heavily on types then successful compilation is a massive indicator in the feedback loop. Using stop hooks to ensure successful compilation after every iteration is a game changer. Go also has compilation of course but because the type system is so much more robust in Rust the compilation guarantees so much more about the behaviour of your program. You end up just code reviewing the shape a…

Code compiling is really the lowest bar of code validation, and doesn't say much of anything of the code running correctly. AI will pump out the most convoluted, over engineered, and at the same time sloppy code if you let it - and it will all compile fine.

It's the lowest bar and that's precisely why you want it to be as high as possible.

For me, one of the bigger complaints is that Rust isn't pedantic enough. Panic free Rust isn't taken seriously enough as an idea.

I wish it would catch even more things, since it works so well.

Re: Migrating from Go to Rust

#349

Earlier quoted context omitted.

Conversely, the Go community tends to actively shun frameworks, especially anything Rails-like, and will tell you to just use the standard library. Which is good advice, the standard library really does have everything you need . But it's also roughly on a par with what's available in Rust (though as someone said above, the Go stdlib routines have been heavily, massively, tested in production by now, and are fully ma…

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?

Most projects I see use the standard library for almost everything, but everyone leverage a few libraries here and there for one thing or the other.

It's just a different philosophy, but it's really not unlike Rails users importing Devise or Sideqik or RSpec.

Re: Migrating from Go to Rust

#350

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…

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

[dead]
Post reply on HN