On: C++ and the Culture of Complexity (2013)

[lmm]

It seems to have many fewer language-level features. No lvalue/rvalue distinction, pointers are not elevated to a language-level feature (only references), only a very limited exception mechanism (panic) that doesn't try to generalize to support general validation (rather general validation is done with Result which is a plain old datatype written in the language, though admittedly it relies on a macro for use - more generally this approach is also used for things like I/O, a lot more is done with plain old library functions written in the language rather than added to the language standard), the macro mechanism is much less of a special case than the C++ preprocessor, no "const" and associated language-level complexity (e.g. "mutable"), smaller and more consistent syntax (no comma operator, no sequence point rules), more unifying things from the start (e.g. traits as values) rather than ad-hoc conversion rules in the language later on.

[masklinn → lmm]

FWIW

> Result which is a plain old datatype written in the language, though admittedly it relies on a macro for use

It does not. It relies on a special construct (!) or macro (try!) for convenience, but these are not necessary (a popular alternative is to use the various HoFs instead) and desugar to pretty trivial (if possibly repetitive) code:

    macro_rules! try {
        ($expr:expr) => (match $expr {
            $crate::result::Result::Ok(val) => val,
            $crate::result::Result::Err(err) => {
                return $crate::result::Result::Err($crate::convert::From::from(err))
            }
        })
    }

[lmm → masklinn]

I don't think Result would be seen as an acceptable replacement for exceptions without the macro/special construct. But I should've been clearer.

[steveklabnik → masklinn]

(It's ? not !)

[masklinn → steveklabnik]

(You're right of course, not sure what I was thinking)