Migrating from Go to Rust

Re:Migrating from Go to Rust by atombender on Sunday May 24, 2026 @07:03PM (#48261897)

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<String>,
        Query(verbose): Query<bool>,
    ) -> 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 convenient compared to Go, and you type validation along with it.

Many other things to like: The absence of context.Context, the fact that handlers can just return the response data, etc.

What I don't like: Async.

[ Parent | on HN ]

Re:Migrating from Go to Rust by ricardobeat on Sunday May 24, 2026 @07:57PM (#48262236)

go is slightly more verbose (surprise) but you can achieve the same thing using struct binding in gin:

    type DatasetStatsQuery struct {
        Verbose bool `form:"verbose"`
    }
    
    func DatasetStatsHandler(c *gin.Context) {
        datasetID := c.Param("dataset_id")
        var query DatasetStatsQuery
        if err := c.ShouldBindQuery(&query); err != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }
        // query.Verbose == bool
    }}

This is actually a great example - what happens in that Rust version when the input parsing fails? Go makes it explicit.

[ Parent | on HN ]

Re:Migrating from Go to Rust by sheept on Sunday May 24, 2026 @11:18PM (#48263117)

I'm not sure if that's a great example. What kind of errors could ShouldBindQuery return?

I would assume Axum returns a bad request error for you when query parsing fails, but if you do want more control over how the error is handled, you can change the parameter type to Result<Query<bool>, QueryRejection>, and the type system itself documents precisely what errors you can match against.[0]

[0]: https://docs.rs/axum/latest/axum/extract/rejection/enum.Quer...

[ Parent | on HN ]

Re:Migrating from Go to Rust by xyzzy_plugh on Sunday May 24, 2026 @08:56PM (#48262511)

The Go standard library has learned to interpret path variables as well:

https://go.dev/blog/routing-enhancements

[ Parent | on HN ]

Re:Migrating from Go to Rust by zimpenfish on Monday May 25, 2026 @04:52AM (#48264780)

To be fair, it's not -quite- as useful - `req.PathValue` only returns `string` and you have to do the conversion to other types yourself which could lead to a faffy mess of code.

[ Parent | on HN ]

Re:Migrating from Go to Rust by winrid on Sunday May 24, 2026 @10:13PM (#48262832)

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

[ Parent | on HN ]

Re:Migrating from Go to Rust by whstl on Monday May 25, 2026 @09:17AM (#48266480)

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.

[ Parent | on HN ]