Just wrt the let/match/Ok/Err == ugly comment: I don't know Rust very well and I haven't looked very closely at the code in question, but why would Rust force you to wrap almost any function call with let/match/Ok/Err, though?
I am assuming the issue at hand here is when you call function that returns a Result (if that's the name of the parent of Ok/Err)?
Couldn't one let the return values 'flow up'? For example: if a function starts returning Results and you don't handle it on the level above, you start returning Results too...
Also, I suppose there's ways of flattening results to avoid having nested Results (I would guess and_then does that based on its signature?)?
In this scenario, you could argue that one now replaces match with map at every function call where you do not actually handle the Err and that this is ugly too, but the alternative is hoping that the caller happens to have read your source code (or have checked exceptions), which is, arguably (to be diplomatic), the case for unchecked-exceptions. Then what happens if you change the code and so on and so on...
This way lets you achieve something similar to checked-exceptions, and in addition to gain composability of Err (and the like), without adding another language construct (which a language without exceptions would have to do).
Got a great deal of experience in other languages that does this, and it's worked out pretty good so far for at least for me once you get the hang of it (i.e. functional coding).
Where I am sitting, that would be a wise choice for Rust, at least if I am understanding it correctly, as it tries to be a safer alternative to other system languages. However, arguably (:), it is OK in dynamic languages or similar that aims trades in correctness for conciseness and, arguable (again :), speed of development to simply have unchecked-exceptions.
Also, it is possible I misunderstood your comment and/or how that code was ugly, in which case I hope the downvotes/replies won't be too harsh :)
EDIT: typo/clarity