Well it's pretty straightforward, if turnaround time is only 10 minutes and your competitors take an hour then you can simply make more flights per aircraft per day than them. This is amplified when your flights are short distance domestic. Depending on destination it probably allowed them to make 2 - 3 extra flights per aircraft per day, at a time when jet fuel was not so expensive. That could make a massive difference to profitability.
Hell, even in a day where jet fuel is very expensive, daily miles is still a key factor. Your margins might be smaller thanks to jet fuel, but more flights still means more revenue.
Possibly diet. Obviously it's anecdotal but all of the Dutch people I know consume far more dairy products than those from the UK.
Edit: Turns out the Dutch are the third biggest consumers of milk per capita in the world[0], looking at the list of "tallest" countries on wikipedia[1], there seems to be a great deal of overlap at the top of the two lists. I wonder if a secondary factor could also be related to vitamin D exposure, but I couldn't find a data source for that.
Over 2,000 years ago Julius Caesar described the people that lived where The Netherlands, Belgium, and Germany are today.
> They do not live much on corn, but subsist for the most part on milk and flesh, and are much [engaged] in hunting; which circumstance must, by the nature of their food, and by their daily exercise and the freedom of their life (for having from boyhood been accustomed to no employment, or discipline, they do nothing at all contrary to their inclination), both promote their strength and render them men of vast stature of body.
It was unquestionably propaganda, Caesar paints himself in the best possible light most of the time, but there is no one who questions the overall historical accuracy. Most of Caesar's military and political life is confirmed by many other sources and pieces of evidence.
I see this line of thinking a lot and I think it's a mistake. Are classes in other languages consistent with each other? Clearly not, so why is this distinction made here? ES6 classes ARE classes, it's not just sugar, that is what they are.
No, it's just syntactic sugar. They're not a basic construct of the language. JavaScript has objects and it has prototypes on objects. ES6 classes are sugar over this. Classes in other languages, however, are the basic construct.
Because when you run into OOP that doesn't use the sugar, you'll have trouble if you'd only learned "class", rather than what it's syntactic sugar for.
I'm sure an equally minimal http implementation using the net module would match or beat that, but since you'd never use either of them in production, the results are meaningless.
I state the point of the comparison in the post: to see how TCL's event loop + my code compres. Node's http module is fairly lightweight, and even if something more minimal would beat my TCL code by a bit it still show what I wanted to, that they are comparable and TCL is an option for event driven servers (at least as far as performance goes)
In retrospect the title is a bit too attention grabbing. If I had anticipated the reaction I could justly be accused of writing flame bait, but I did not expect it to get so much attention or debate - I thought just TCL people would be interested!
1. Node is not a language it is an implementation of a language, so the title would really be TCL vs JS or Dandelion vs Node...
2. In which case you would be opened up not only to performance benchmarks but usability, simplicity, and features - whether you are talking about the language or the implementation.
That being said, I have nothing against your opinions or work though and understand that your implementation is also from 2008 :)
> TCL has been battle-tested for decades, even in industrial automation...
Right but I believe the point was that this http implementation was less battle-tested than node's and that if you're willing to strip away features from the node version, it too could outperform node's version in a microbenchmark.
I mean, I love Node for building my webapps, but if I had to write a fast HTTP server for pure speed I'd probably go with C. But I use Node for NPM just like anyone would use Ruby for Gem. It makes it easy to get a production ready rest app upp and running. I agree with what you said, I don't see the point of this comparison.
Labour costs. TBMs are amazing but they are slow and require a whole lot of infrastructure. It's not just a case of sticking them in the ground, turning them on and waiting for a nice tunnel to materialize. For instance, what do you with the excavated dirt? To give you an indication of the sheer cost here, London's crossrail project runs at approximately £4m/day - https://en.wikipedia.org/wiki/Crossrail
Some people build "graph databases" on top of storage backends that are ill suited for such workloads. e.g you can build a "graph database" (or K/V store) on top of MySQL, but the performance is terrible - http://java.dzone.com/articles/mysql-vs-neo4j-large-scale
a "native graph database" is one that is actually designed for the task.
OrientDB fails to deliver on its promises. It has a load of features but they are poorly thought out and/or broken.
ArangoDB is OrientDB done right, but it's a lot younger.
If you're considering using either, you owe it to yourself to investigate whether postgres's Common Table Expressions [0] can do what you want instead. If you can stick with something more mature like postgres, then you'll be saving yourself a lot of pain.
It's my opinion based on working with OrientDB a lot and ArangoDB a bit for the last 12+ months. I used to be a big cheerleader for OrientDB, but now I don't recommend it. I'm sure Luca will have some comments but he's interested in selling his product.
Guys, IMHO I think Charles Pick (alias phpnode) doesn't deserve such attention. Even if he's trying so hard to start a flame against OrientDB I'd rather like to celebrate the Multi-Model approach. Long life to the Multi-Model approach ;-)
I've been using OrientDB for the last 7 months and as such I've been following @lvca and @phpnode (OrientDB node.js driver creator/maintainer) work closely. I have great respect and admiration for both and for what they've achieved!
@lvca, I find your comment distasteful and it's not the first time I see you trying to shutdown people who criticise OrientDB (https://news.ycombinator.com/item?id=9253488) when you should really be thanking them for exposing the issues they face (a lot of people don't go public). It would be more productive to engage @phpnode, @anonwarnings and others, listen to them, raise issues in the bug tracker and address them. Accusing people of trolling or flaming doesn't benefit OrientDB or its users at all...
Unfortunately I haven't tried ArangoDB so I can't make any comparisons with OrientDB but I hope both succeed!
@dmarcelino always open to constructive criticism: the OrientDB Community Group has thousands of users that report their feedback every day. No one was banned nor accused for that. The case with @phpnode is much different for a lot of reasons, but this is definitely not the place to discuss it ;-)
Given that the posted article is about ArangoDB I don't want steal their spotlight by turning this into an OrientDB discussion. Send me an e-mail with your questions and I'll be happy to answer them.
It's a database that stores a "graph" of vertices that are connected by edges. If you were say, creating the next LinkedIn and you wanted to find the shortest path between two users based on their connections, a graph database would be a good choice.
Let's imagine you want to see how Fred is connected to Steve, their network looks like this:
A "traditional" database like MySQL or Mongo makes this kind of query prohibitively expensive and complicated, as it must perform a new join for every connected person in the user's graph.
Graph databases come into their own because they are designed specifically for efficient traversal of these connecting edges. They typically do this by storing "pointers" on each vertex to its connected edges, so while a normal RDBMS requires something like a hash table lookup to resolve a join, a graph database can simply "jump" to the relevant record via a pointer. This means that things like Dijkstra's algorithm [0] can be implemented efficiently.
However, "traditional" graph databases like Neo4j require everything to be structured in terms of vertices and edges. This is often quite inconvenient, so Multi Model databases like ArangoDB integrate this graph approach with a document store as well, the idea being that if you can keep everything in the same db your app gets a lot simpler, you regain things like ACIDity that you'd normally lose by using 2 separate dbs, and performance should be a lot better too.
