The one thing that stood out was the custom error type that wraps up Anyhow (which is a glorified Box<dyn Error + Send + Sync + 'static> aka void* for errors).

The one thing that stood out was the custom error type that wraps up Anyhow (which is a glorified Box<dyn Error + Send + Sync + 'static> aka void* for errors). What would actually be done for such an app would at least be one variant for each error type you can encounter (e.g. Db(sqlx::Error), Api(reqwest::Error), ...) with something like thiserror. Then in the conversion to Response, there'd be a (admittedly) large match that maps out every error kind to a response code. In this example, they conflated both the external api request and database error to a 500, while before they properly made the api request a 404 (which is not always the case), and the db error to a 500. For real apps you gain a lot. By doing this legwork, you get terrific developer experience as virtually all errors that can happen get mapped to a proper status code and handled by a single `?`, and terrific user experience as all errors ... (you get the idea). Don't get me wrong, that's still an improvement! They do show it is easy to have the infrastructure to do so. In the go version, there is literally no thought given to this. Sprinkle return c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()}) everywhere and done!