Biggest annoyance with this software - backspace is, apparently, something that I alone exercise. If you type an incorrect letter, it simply doesn't advance the cursor rather than advancing the cursor and marking the letter as incorrect. Since I am already a pretty good touch-typist, I routinely KNOW I have hit an incorrect key, hit backspace, and correct it and progress with the word.
However, very often I will do something like spelling "icnorrect" from feeling, then hitting backspace exactly eight times and re-type "ncorrect"... which is simply not supported by this software.
We aren't trying to measure each hardware set as apples-to-apples, but rather give the reader an idea of how performance characteristics for a chosen stack are affected by hosting environment. Specifically, we wanted the middle-of-the-road EC2 instances versus the extremely high-end Peak option to illustrate that difference.
Our suite takes a nuke-from-orbit approach when it comes to killing processes, as this has come up in every round. The idea is that now all tests are run with a specific user, and instead of relying on the test to shut down properly (which MANY could not reliably do), we simply nuke all processes owned by this runner.
It has the downside that if a process forks other processes and drops them into another different user (recently addressed for hhvm, for example), we cannot capture that. However, we have made great strides in trying to avoid that. Additionally, the logging for the application WOULD suggest if a port were bound prior to start-up, and that does not seem to be the case in this example.
Agreed. Our logging has undergone some solid improvements in the last week or two, and so round 11 will, if not resolve this issue completely, make the logged output more useful for tracking down issues like this during the preview runs.
Rust and Elixir SHOULD be included in Round 11 - we have already accepted a pull request for the Phoenix framework (Elixir) and have had a pull request for Rust when it was in alpha. Hopefully, we will see another Rust pull request soon.
Actually, not really. We checked the code to ensure that there was no gaming the system and it definitely APPEARS to be making separate database queries as we require in our rules. In fact, we had this same question in round 9 and had a number of people audit it. We cannot explain it other than it might be pretty darn fast.
I just posted another response to this - we had some trouble with the package manager for Erlang after round 6. Additionally, I had been working on improvements for the suite specifically (better logging/reporting, etc) and did not get a chance to resolve the Erlang problems.
Rest assured, "get erlang running again" tops my 'todo' list for round 9.
We have been having trouble with Erlang frameworks since before Round 7. Unfortunately, I was still getting up to speed and improving the suite mostly for Round 7/8 and did not get to fix this yet. I do have it topping my todo list for round 9, with the hope being to get them all back in and working soon.
In my opinion, you hit the nail on the head with regard to a view on Java (being that it is "slow"). For many years in the early going, it was slow, but it has come around so much.
That being said, as a day-to-day Java web-developer, I cannot honestly remember the last time I wrote "public static void main".
"Humans are fleeing California, looking for a better life!" - CBSNews