3 ms·
> While the Rust in this article could be a bit better (though that's nitpicking and explicitly not the point), How so? While the Go seems very high quality, t
by mighmi 3y ago
> While the Rust in this article could be a bit better (though that's nitpicking and explicitly not the point),
How so? While the Go seems very high quality, they are a Rust shop so I assumed the Rust is even better (I don't know Rust).
- tuetuopay 3y agoThe 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!