> Which operates by immediately dumping the "errors" to terminal without any error types involved whatsoever I haven't looked at your code, but if I take this

> Which operates by immediately dumping the "errors" to terminal without any error types involved whatsoever I haven't looked at your code, but if I take this sentence at face value, I'd be very hesitant to use your library in many contexts. One example would be anything similar to a web server, such as an API that accepts JSON via a HTTP POST. It would be very strange to have my JSON parser print to the console where no one is reading! A lot of your comment indicates similar focus on a human interacting with a terminal, which is a very valid usecase, but not the only usecase. > instead of trying to structure data to leave the task of actually reporting the error to someone else, and kicking the can down the road. I agree with this in broad strokes. I think that it's very important to use your error types to ensure that they provide value. For the JSON example, I think that I might have an error that indicates the specific error as well as a byte offset that the error occurred. This could be built on by higher level errors that convert to line/column numbers or attach an excerpt of the bad input, as appropriate. These types could have methods or implement traits that allow formatting for the console (considering optional coloring, etc.) or be formatted for a logging system. > an unrecoverable bug should perhaps instead log and then terminate I technically agree, but I have a very high bar for when a library I write is allowed to unilaterally terminate the process — it's simply too drastic of a decision to make in most cases. I also hope that the act of logging is appropriately abstracted. Thankfully, Rust only has a few common logging interfaces so it's easy to fall into the pit of success there.