I think it would be worth sharing that on a blog post submitted to HN. Sounds like a lot of work, maybe there are ways to automate that with a shell script or a Haskell program. 400KB is absolutely okay I think.
What is the 3 color chart that I've seen posted in several of these articles? I get that it breaks down the different CAP combinations with the things that it allows/implies. But is there a good breakdown of all the terms and what they mean?
Here is a paper  out of Berkeley that explains the chart you're asking about (the chart appears on page 8). For more information on each isolation level you might have to refer to the cited works or other sources.
The afl fuzzer relies on compiling C code with its own compiler, so I think it's limited to only C based programs.
What you may want is to use something like `quickcheck` (scalacheck or clojure's test.check I guess?) to send lots of "arbitrary" xml at your code and see what breaks. With sufficiently interesting definitions of "arbitrary" you can probably find bugs.
That approach would be testing inside the process, as opposed to passing in whole http requests. But if you know a section of code is more vulnerable than others, focus on it. No need to test all of tomcat's http parsing when you really care about your specific library.
This can't be about backwards compatibility. If it was, they wouldn't have been able to add 'yield, 'await' etc.
I don't agree the keyword "generator" would have been ideal. It wouldn't work when using 'enhanced object literals' , where you can declare a method without even using the keyword "function". In this case, if you want the method to be a generator, you can just put an asterisk in front of its name, so it's consistent with the "function*" syntax.
It's only valid as a keyword within the `function*` block, so the parser can treat it as an identifier elsewhere. I haven't read the detailed spec, so I'm not sure that this is the standard behavior, but this would be a way to preserve complete backward compatability.
AFAICT, `async function` is OK, because you combine a keyword with something that is contextually turned into a keyword. With a single non-keyword that isn’t possble. For example, the following code (a hypothetical ES6 anonymous generator expression) could be an ES5 function call followed by a code block.
That's why it wasn't included in the ecmascript 6 draft. In es6, "async" and "await" are future-reserved keywords. It's kind of a process of marking variables named "async" as deprecated. The spec authors have to balance compatibility with making the language pleasant to use.
I don't think googling is much of an issue here. Unless you're talking about the very first occasion that someone sees "function*", then OK, they can't google for that easily... But they can google "function with astersik" or something and they'll find out it's called a "generator", and use that in future.
I keep tax and similar docs on dropbox inside a truecrypt encrypted disk. Suitable level of security for my needs, and I like that its synced across a few systems (including one that is separately backed up).
Its riding the haskell bandwagon to some degree. By borrowing ideas from category theory they have some really nice abstractions in practical code. But then it gets more confusing so you want to loop back and see what the actual definition of a "monoid" is, or understand "functors". Even if haskell's idea of functor isn't 1 to 1 with category theory's.