Agreed. The reason the arangodb team give is the different concurrency models between arangod and node, but I don't think the problem is insurmountable. From the programmers perspective it would be no different from using node's cluster module.
> If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild.
This is exactly right, pushing language features into user-land just leads to a load of competing equivalent solutions that developers must learn. The language is simpler but it becomes harder to actually use.
It was very much a hostile takeover. If I remember correctly, the people who controlled the infrastructure like the website and mailing list booted out not only Michael but also a bunch of the existing maintainers of ffmpeg code and it got really ugly.
Hey, this looks really fantastic, it solves a real problem for UK drivers and I think you'll be fantastically successful. However, I couldn't find any information about who's behind the site, and I wonder about the mechanism through which the insurance is provided, how is it backed?
We are authorized & regulated by the UK Financial Conduct Authority as an intermediary. We have built a partnership with a European underwriter to sell policies on their behalf.
To make Cuvva possible, we've had to build every part of the system from scratch. This is mostly in Node JS, with some RoR thrown in. We also have some open source code on our Github - https://github.com/cuvva
Wow, it was so long ago, I don't remember the exact data structures, but I'm pretty sure it wasn't a skiplist.
If you've already asked, one cool part of that technology is that the order of received packets is not important to assemble the stream. Basically every 1 second of video is reassembled without importance to the order of packets received. You need N packets to assemble a "data frame", IIRC pending incomplete data frames were stored in a simple hash table, but honestly it was so long ago I don't remember.
The fact that your tests are flaky at all means that the integration tests have revealed a bug that you need to fix. The tests have done their job. The fact that people aren't looking at the results speaks to a larger cultural issue.
Not if it's a timing error in the test harness. That's usually what people mean when they say flaky tests. Selenium, especially three or four years ago, would simply fail occasionally no matter how good your tests are.
Yes, there are bugs that look like bad luck, but are really flaws in your logic. I have fixed a lot of bugs that look Random, but eventually you're left with, for instance, selenium just refusing to click a button.
inglor is a contributor to Bluebird, so I'd guess he'd say Bluebird. Bluebird is the much faster option and has a lot more features, if you're using babel (and a recent node/io.js) you can transpile async/await to bluebird coroutines for maximum performance and syntactic beauty.
Is there any chance Bluebird will become the standard in the future? Not sure if it makes sense to use a nonstandard approach, but would love to be convinced otherwise.
IMHO, very doubtful; Bluebird has a lot of (very useful) features that would be pretty burdensome to put into a specification.
On the other hand, there's really no reason not to use Bluebird. It's easy to ensure that a promise you receive is a Bluebird promise:
import Bluebird from 'bluebird';
const bluebirdPromise = Bluebird.resolve(promise);
If `promise` is a Bluebird promise that will be a no-op, and if it's a foreign promise or thennable you'll get a new Bluebird promise that will resolve/reject when the foreign one does. (This is standard behavior; see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)
Since Bluebird promises are thennables, the reverse will be true if they're consumed by a different promise library.
Given Bluebird's speed, superior debuggability, and features, there's really no reason not to use it a this point.
