#1 I find is not worse than C++, granted there's more complexity here than in Python but in terms of cleanness its ok IMHO. Because as you said there's nothing unnecessary. Rust addresses different problems than Python, so we should compare apples with apples.

On the second one you got me though, I find the macro syntax a bit horrible. Sometimes I just want simple text substitution.

I'm comparing it to Haskell syntax for the same thing, which is much cleaner

Haskell does not have borrowing and lifetime specifiers though, which is what makes the Rust example more dense.

Haskell has nice syntax for generics, no stupid <> to forward declare type parameters

C++ templates also aren't winning any readability awards.

It is somewhat unfair to compare this to Python, since a lot of the simplicity in Python comes from the semantics (dynamically typed, garbage collected and so on). Rust need to express all this information (types, lifetimes etc.), so it will necessarily be more dense. The question is if this information could be expressed in a more readable syntax. This might be possible, but I would like to see a suggestion of how.

I guess the signature could be made more readable by using a few type aliases. The hardest part to read is the nested types.

I'm with you on the macro syntax, it is very hard to read. It is not easy to create a readable macro syntax though. All languages I know have hard-to-read macros, so this is not yet a solved problem.

Here is a simpler syntax:

   fn accumulate tuples: &[(&'a Str, &Fn(i32) -> Bool)], i: i32 -> t
   where
        t: Monoid + From &'a Str + From String,

this is how Haskell with lifetimes and borrowing would look like (if arguments were not curried)

This is arguably less readable, because it's missing some delimiters for your eyes to latch onto.

It's also not realistically parseable- the Haskell/Ocaml-like removal of <>s and ()s relies on application being left-associative, and if you read this under that rule you've changed the meaning (e.g. `From &'a Str`).

I like removing superfluous punctuation, but if parentheses are removed from method signatures than they should also be removed from invocations, which in turn comes with its own set of readability issues. I'm not a fan of the $ operator in Haskell, for example.

This also reminds me that, in Python 2.x, the following code...

for i in range(100000000):

...creates in memory a list with one-hundred million integers.

Expressive yes, but sometimes it can be double-edged for new comers (and not new comers).