> If unwrap() works for you, why not use the try! macro Unwrap only works in a loose sense. Writing a parser generator, I want to have it give usable parse err

> If unwrap() works for you, why not use the try! macro Unwrap only works in a loose sense. Writing a parser generator, I want to have it give usable parse error messages. Sometimes this can be done easily with a try!, but many times I should be doing a bit more processing on the error in order to get things like line numbers, input samples, and expected alternatives in the mix. > and I write thousands of lines of Rust code a week This is what I think I need to be doing ;). I'm not convinced yet that what I'm trying to do can't be done elegantly in the language, it's just uncommonly hard for me to "get it." I've been writing code professionally for 14 years, and have used over 30 languages in various sized projects during that time, and Rust has given me the biggest skill-check of the bunch. I actually think that my experience with other languages that have similar abstractions is getting my way more than helping. Regarding HKTs, I'm not 100% certain they would solve my problem, but I frequently find myself wishing I could work in that space. I definitely miss Haskell's do-notation, which I think would be a potential feature in the language with a true monad (I realize there's a macro for it currently, but I haven't played with that yet). In my original comment I said that my problem was a feedback between algebraic data types and borrow checking, but I think on further reflection that it would be more accurate to say it's between closures and borrows. The and_then function of Option and Result allows me to use them as monads, but doing so means I make lots of one-shot closures. I think the interaction that keeps stalling me is actually there, frequently with the &mut self from the parent function being used inside the closure in a way that's not allowed, or with a non-copyable type being used in the closure. I can get around it with some matching, testing, and unwrapping, but it doesn't feel nearly as solid and clear as the and_then approach. I think Rust is an awesome language so far, and I think it's "shortcomings" are likely really my own shortcomings, but I have to say that it's been full of surprises so far. The advanced features I keep expecting to have seem to be locked away behind memory management barriers. I'll definitely keep working with it, and I suspect that I'll never turn back to C++ if I have the choice, so it's a triumph in that regard. It's just so tantalizingly close to being the "one true language" that I'm constantly expecting things of it that probably aren't quite realistic.