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

141–150 of 544 posts

Re: Migrating from Go to Rust

#141

Post by winrid »

tertasrfg wrote: post #139
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…

The funny thing is: All Rust source code looks like an assembly syntax error.

If you spend an hour skimming the Rust Book it's not really that bad

Re: Migrating from Go to Rust

#142

Post by winrid »

atombender wrote: post #96
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 backend web dev, there are advantages. I really like Axum's use of typing: pub async fn dataset_stats_handler( Path(dataset_id): Path , Query(verbose): Query , ) -> impl IntoResponse { ... } With a route like: .route("/datasets/{dataset_id}/stats", get(dataset_stats_handler)) …the "dataset_id" path variable is parsed straight into the dataset_id arg, and a query string "verbose" is parsed into a boolean. Super co…

You can not use async right? Maybe not with axum but I imagine there are fully blocking frameworks for rust.

Re: Migrating from Go to Rust

#143

Post by zjy71055 »

I was a Go engineer for years and have shipped a lot of Go. I never properly learned Rust.

Over the past year I've been using AI to write small Rust tools for myself — I barely read the code, and honestly it just works.

But for serious projects I expect to maintain long-term, I still pick Go. Today I want code I can actually own and reason about myself.

Give it a year or two and I probably won't be writing code by hand at all. Once the AI owns the code anyway, that reason disappears — and at that point Rust's guarantees win. So I suspect I'll end up leaning Rust.

Re: Migrating from Go to Rust

#144

Post by hebetude »

Not sure the article is … accurate? Go has a large standard library. Rust leans on third party cargo libraries which fall into the supply chain attack and has a small standard library. Anyways, that feels immediately biased in the article. Also 11% use Rust? I don’t see that penetration in real long term products. Sure lots of tui apps these days but not things that you can make money working on.

Re: Migrating from Go to Rust

#145

Post by throwaway894345 »

ViewTrick1002 wrote: post #114
throwaway894345 wrote: post #109

Earlier quoted context omitted.

I’ve repeatedly tried using Rust and the error handling has tripped me up every time and has been ~90% of the reason for moving a project back to another language. I’m sure I’m just holding it wrong, but what I run into usually goes something like this (mind you, I have read the Rust book): * Someone tells me to use enums for errors, in a comment like yours * I try writing the enums by hand, implementing the error tr…

How come you get macro expansion errors? Or is it because you write incorrect syntax in the enum error definitions? The example on the docs page is quite clear: https://docs.rs/thiserror/latest/thiserror/#example Including all kinds of errors: Strings, tagged unions and automatically converting from std::io::Error with added context. That one page document is the entire documentation for the thiserror crate.

It’s been a while, I don’t remember the details, but it wasn’t syntax errors.

Re: Migrating from Go to Rust

#146

Post by cobbzilla »

dnautics wrote: post #136
dwattttt wrote: post #111

Earlier quoted context omitted.

Do you really want that data passed back down to the caller of the allocation? From the description of the failure state you'd want to log that data instead: what's the caller of the allocation going to do if you tell it it failed with a crazy size? It already knows the size, it's the one who asked for it.

So, suppose it's a rust library -- you're locking me into whatever logging system the library author chooses? Maybe I'd like to consume the relevant data at the entry point and send it to a logging system of my choice.

usually “stdout” is good enough, wrapper/runner routes output to logserver for collation and search. who cares about formats as long as it’s reasonably structured and searchable?

Re: Migrating from Go to Rust

#147

Post by runhelm »

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…

[flagged]

Re: Migrating from Go to Rust

#149

Post by netheril96 »

I've swinged between Go and Rust for my personal projects multiple times. For work, it is decided by the management so not my problem.

The biggest gripe I have with Go is the lack of *any* compile time check for mutex. Even C++ has extensions like ABSL_GUARDED_BY. For a language so proud on concurrency, it is strange not to have any guardrails.

Re: Migrating from Go to Rust

#150

Post by whilenot-dev »

hebetude wrote: post #144

Not sure the article is … accurate? Go has a large standard library. Rust leans on third party cargo libraries which fall into the supply chain attack and has a small standard library. Anyways, that feels immediately biased in the article. Also 11% use Rust? I don’t see that penetration in real long term products. Sure lots of tui apps these days but not things that you can make money working on.

> Also 11% use Rust?

These percentages are from the JetBrains State of Developer Ecosystem Report 2024 on the question "Which programming languages have you used in the last 12 months?"[0].

I think a better datapoint would be the "Primary Programming Languages" in the 2025 report[1] where Rust sits at 4% and Go at 8%.

[0]: https://www.jetbrains.com/lp/devecosystem-2024/#KeDHWJ

[1]: https://devecosystem-2025.jetbrains.com/tools-and-trends

Post reply on HN