Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Reading this blog post I get the feeling the author is attempting to solve a problem that doesn't really need to be solved in rustc in my opinion. unwrap() typically wouldn't be in any application you actually care about errors beyond initial debugging. In production you'd either deal with the error in a sane way or fail gracefully (panic-persist or panic-reset make a lot of sense in those scenarios). For actually doing a log like format on a arm cortex-m I'd be looking at ufmt as mentioned in the post.

That's not to say the post isn't enlightening. It is, the cost is unexpectedly high in space. That's not to say that the goals of making unwrap and panic more space efficient are good ones as well. I don't think they're a concern I personally have with rust in an embedded system though.



.unwrap() in production code is perfectly normal where the author believes other code constraints outside the scope of the type system prevent it ever having a non-truthy value. Technically the author should have used `.expect(...)` instead with a message but even if the author were to write a `match` instead, the author would have panicked in the _ case. (Think erroneous design assumptions or logical errors.)


Note that it's very rare to end up with programs with provably zero instances of panicking. Even .unwrap() is okay to have if you don't use it for errors but signaling fatal, unexpected logic bugs. Every instance of array indexing have bound checks, and thus panics. The formatting machinery is going to end up in your binary if you don't make special precautions for it not to.


It's not just unwrap, it's anything that ends up using format!. It gets used in production all the time, not to mention cases where you know an Option is a Some-variant so unwrap'ing is safe.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: