> If any American English native speaker has time on their hands, I'd be grateful if you can tell me the differences between my writings (you can click on my username for more samples) and those of an educated native American English speaker.
> So, dear native speakers, which is more appropriate in my use in the GP comment? writings or writing? :-)
Definitely "writing". An author might refer to books that he wrote as "writings", but it would sound odd (or even pretentious) for anyone to refer to their posts on HN that way. Besides, you're not really asking about your previous posts, but about your ability to write English in general. So it's your "writing" (in general) rather than your "writings" (the particular posts you've made here).
"The new powers are supposedly intended to help the government combat the promotion of extremist videos promoting terrorism."
As long as I see "This video was flagged by the UK government for terrorism" on the video, I'm ok with this. If terrorism was your reason, then own it. "We denounce this video because it is terrorism. Signed, the UK." Show that message to users.
If by "syntax compatibility" he means code that compiles in one version does not compile is another, that's definitely true. Name collisions with the new default methods in Java 8 are one source. If your Comparator-implementing class has a method "void reverseOrder()", that will no longer compile.
Here's a couple of recent examples the Guava authors have fixed. Fortunately they were in internals and not their public API, so users won't care.
He qualified it with "(of types)", so I believe he was talking about inheriting from multiple interfaces. People already had to be able to deal with "this thing is both a Foo and a Bar", so perhaps it's not a huge leap to go from there to "this thing inherits implementation from Foo and Bar". And by implementation we mean methods, not state.
> You should really avoid publishing incomplete benchmarks.
If we had followed that advice, there never would have been a round 1. I was so uncomfortable with the idea that we'd be publishing surely-flawed benchmarks of frameworks we didn't really understand that I requested to be taken off the project (prior to round 1). It was only after seeing the post-round-1 discussions and the flood of pull requests that I realized I was wrong.
These benchmarks are always going to have flaws. I think it is better for us to regularly publish our best attempt than to try for perfection.
I think we used to have a brief description of each test in the results section as well, and they somehow got lost in this round. We should add them back; how is a new reader supposed to know what "Fortunes" means?
Vert.x was in our original batch of tests (round 1). At the time, its documentation showed that using the persistor and event bus was the standard intended mode of communicating with a database. If someone can point us to documentation showing that is no longer how you're supposed to use a database with Vert.x, we'd be happy to accept a pull request that changes the test. Otherwise, I think it's valid as is, and not misleading.
Right. Related to this, I feel like a couple of frameworks are cheating on the plaintext test because they aren't actually testing string... serialization. They encode the "Hello, World!" string into bytes once, retain those bytes in memory, and send those bytes on each request just to avoid encoding the string again.
It's such a small, silly optimization. It doesn't bother me because it's not going to affect the overall results much, but I do feel it's against the spirit of the test. That kind of thing would be prevented if we made the test echo a request parameter, as was suggested elsewhere in the comments.
This is sort of getting off topic, but... I agree that annotations are magical. The good news is that they announce magic is happening. When I see unfamiliar annotations in Java code I know to look at their javadocs. I like that kind of magic much more than magic by convention (e.g. the location of the given file on disk).
> But for me all this seems quite biased towards small Frameworks/Platforms.
If one framework does less than another while still fulfilling the requirements of the test, then it ought to outperform that other framework, right? I don't see that as a bias; it's the expected result.
I said "does less" rather than "is smaller" there. I think that's an important distinction. It's theoretically possible for a framework to provide a feature at zero cost to users who don't use that feature (in responding to a given request). Some frameworks don't do that.