tikue_

Backwards-compatibly changing existing features feels qualitatively the same to me as adding new features. In either case you can ignore them until you need to work on a codebase that uses them.

At least in Rust, capture granularity is per-variable, so I think closures don't contain a stack frame pointer? Though, I'm not sure why this would matter to a user evaluating Rust's closures vs. D's nested fns?

Saying library authors are content with their absence is probably a bit too strong. There's not really another option, and I doubt many folks would choose not to author libraries for this reason alone. I personally have found their absence annoying when writing Rust libraries.

I'd probably be in favor of a hard cap on # of function arguments. :)

Functional typically implies higher-order functions, of which there are none in that Python code.

What's it like working with Rust full-time? Is it similar to using any other language for a job? Do you find yourself enjoying coding more? Do you get unnecessarily caught up in micro-optimizations for things you wouldn't blink at in Go/Java?

Every language has different idioms. In many cases, what works in C++ doesn't work in Rust. Generally, anything the book says is bad you should take as qualified to mean bad in the context of Rust programming, not programming at large.

They have them in the Czech Republic, too. I've been on one in Prague.

I wish `and_then` were named `flat_map` so badly.

Also seems like you could benefit from the entry() api (available on both BTreeMap and HashMap):

http://doc.rust-lang.org/std/collections/struct.BTreeMap.htm...

I think the example used in the docs is your exact use case.

This bit:

  let found = match map.get_mut(..) {
    ..
  }
  if !found {
    ..
  }

can be replaced with

  match map.entry(word) {
      Occupied(mut view) => { *view.get_mut() += 1; }
      Vacant(view) => { view.insert(1); }
  }