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

351–360 of 544 posts

Re: Migrating from Go to Rust

#351

Post by 63stack »

simonask wrote: post #316
63stack wrote: post #233

Earlier quoted context omitted.

Any time I mention "but I would like stacktraces with my errors" I get told I'm doing it wrong.

That's because the types of errors where you want a stack trace are a relatively small subset of all possible errors. 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. Rust projects tend to favor panicking over error hand…

See? You get people explaining to you that you actually don't want a stack trace because xyz.

Re: Migrating from Go to Rust

#352

Post by whstl »

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…

A project I work at uses a similar pattern (similar from what I can see):

    func Login(req LoginRequest, cookies Cookies, db *sql.DB) (LoginResponse, error) {
        ...
    }

    router.HandleFunc("POST /signup", fw.Wrap(Login))
It's just a wrapper.

It also serializes/deserializes responses and handles both JSON and templates.

db is just a singleton-lifetime dependency, we often also have ctx, http.Request, http.Response, Cookie, which are request-time lifetimes.

I thought about open-sourcing it but most Golang developers seem to hate it with a passion, so I just gave up, haha.

Re: Migrating from Go to Rust

#353

Post by Certhas »

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.

Yes? Does that contradict anything I said?

Re: Migrating from Go to Rust

#354

Post by apatheticonion »

I wrote Go professionally for years. Moved to Rust and couldn't be happier. There are some annoying syntax quirks but they are minor.

After writing web services, GUI apps and terminal apps professionally in Rust, I honestly struggle to see a use case for other languages.

Re: Migrating from Go to Rust

#355

Post by fHr »

amazingamazing wrote: post #7

Rust is great. However in an agentic world go will win. Look no further than incremental build times. This, combined with high token costs mean that for a given application it simply will cost more to to write it in Rust than Go. This can easily be justified for many usecases, but for your vanilla crud app, do you really need Rust? Per the article, you are getting 20-50% better more performance with Rust. Not worth i…

lol no

Re: Migrating from Go to Rust

#356

Post by fHr »

OtomotO wrote: post #17
amazingamazing wrote: post #7

Rust is great. However in an agentic world go will win. Look no further than incremental build times. This, combined with high token costs mean that for a given application it simply will cost more to to write it in Rust than Go. This can easily be justified for many usecases, but for your vanilla crud app, do you really need Rust? Per the article, you are getting 20-50% better more performance with Rust. Not worth i…

It's a good thing then, that the AI hype is dying outside of ycombinator, the silicon valley and the US

Surely

Re: Migrating from Go to Rust

#357

Post by tcfhgj »

nihsett wrote: post #200
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…

> and it's easy to make catastrophic mistakes

such as ... ?

Re: Migrating from Go to Rust

#358

Post by k8s-1 »

throwaway894345 wrote: post #109
ViewTrick1002 wrote: post #34

Earlier quoted context omitted.

They all convert seamlessly, and the enums make the branches explicit. Don't even need to check the documentation to find which errors supposedly exists like in Go with its errors.Is, errors.As, wrapping and what not. An easy rule before you make a knowledge based choice is Thiserror for libraries, helping you create the standard library error types and Anyhow for applications, easy strings you bubble up. Or just go…

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…

[flagged]

Re: Migrating from Go to Rust

#359

Post by za3faran »

nicce wrote: post #332
p2detar wrote: post #303

Earlier quoted context omitted.

> as amazing or fast as Rust For cli tools, game engines, etc. certainly so. But what about monoliths? Do we have enough data to say Rust handles long-running monolith apps exposing web and other network services better than the JVM with its hot spot? I haven’t come to any stats on that matter, yet.

> other network services better than the JVM with its hot spot? JVM hotspot optimization is just band-aid for something Rust does always everywhere naturally? Assuming that you use lifetimes etc properly and not going to Arc rampage.

Rust:

    concat/string           time:   [77.801 ns 78.103 ns 78.430 ns]
                            change: [+0.0275% +0.3169% +0.6169%] (p = 0.03
Java

    Benchmarks.concat      string  avgt   15   8.632 ± 0.105  ns/op
    Benchmarks.format      string  avgt   15  64.971 ± 1.406  ns/op
Java's string concat is faster than rust's offerings.

Re: Migrating from Go to Rust

#360

Post by tcfhgj »

risyachka wrote: post #239
PaulRobinson wrote: post #230

Earlier quoted context omitted.

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.

In order to use C you need to actually understand it, also toolchain is more complex etc. Which makes it a no go for 99%. Rust is so safe that anyone can vibe it without any idea what is going on there. Which is basically what is happening here. And why rust is more used than go for vibecoding? Mostly because of hype and performance gains which 99.9% of projects do not need.

> performance gains which 99.9% of projects do not need.

most software isn't "needed"

Post reply on HN