moonpolysoft

I'm going to go out on a limb here and speculate that you may be "seeking technical cofounder."

What I find objectionable about the video is not his identification of team quality being the problem. It's his total abandonment of responsibility for it as a founder. That he'd say he just woke up one day surrounded by B and C players he hadn't interviewed makes it seem like everyone else was running amok and he is not to blame. Trashing the reputations of his ex-employees in order to save face on a tech show is irresponsible at best, and at worst a demonstration that he is unfit to lead a team of any size.

This is the best issue tracker I've ever seen. A+++++ would buy again.

Dingus.

You should put your money into gold bullion as a hedge against inflation.

Forever a node.

Amazing. Cue the stampede of aspie HN literalists.

Your rite. Next time I will spellcheck before taxing the runway.

Not really. Me and whiskey have moved in together and are contemplating having some kids.

> There is no value in being precise

Are you an engineer? I ask because I find it very hard to believe an engineer would write that.

Egads man. Keep it safe for work.

Your right. All this talk of distributed systems is making hacker news too nerdy. Lets go rate someone's startup and find a technical cofounder. Perhaps we might also watch a video of a prominent investor trying to promote his personal brand.

> My bank transfers to other banks take a couple of hours, but I don't live in the US. The money comes out of the account instantly though.

What happens between the time the money is debited from one account and it shows up in the other? Hint: it's not a transaction in the ACID sense of the term.

I would address the rest of what you say, but I'm afraid I cannot help you on your reading comprehension. I encourage you to read the article. All the words please.

What is this wonderful bank you use where transfers between accounts at a different bank happen instantaneously? Every time I've tried it the process takes 1-2 days and most likely has to go through an ACH.

As for credit and debit charges, my bank always has two transaction histories. Cleared transactions and pending transactions. Pending transactions are merely funds that have been reserved against your account and they may or may not clear after a period of time. Sounds like that fits pretty well with eventual consistency.

Sharding puts you in the same risk category as any other distributed database. Just ask the engineers and ops people at twitter, foursquare, and any number of other web companies that have dealt with sharded databases at scale. Also: sharding is eventually consistent, except you don't get any distributed counter primitives to help figure out which replica is telling the truth.

> Solving the problems of distributed systems is incredibly hard and not necessary if all you need is scalability and high availability.

Once one scales beyond a single node the system becomes distributed. Then by definition one must deal with distributed systems problems in order to achieve scale beyond the capabilities of a single node.

> When you decide to give up consistency, your application can no longer assume consistency ever. Giving up availability in case of network partition means few extra minutes of downtime a year.

Depends on the application. Giving up availability might mean cascading failures throughout your entire application. For instance if the datastore is unavailable for writes then any kind of queueing systems built around the DB (a common design pattern) run the risk of overflow during the downtime.

And I would make the argument that once an application scales beyond a single datacenter it cannot help but give up strict consistency under error conditions.

> I don't think he completely misunderstood distributed systems - I think he decided to completely side-step the entire field.

If he didn't misunderstand them then he is purposefully ignoring the hard problems. Which is worse?

Wherein Stonebraker misunderstands distributed systems engineering completely.

What does this look like, quora?

8=============D~~~

So last time I looked at it, Node.js did not have any language level or even library primitives for message passing. At least nothing beyond making you open a socket and work out your own protocol for IPC. I'll grant you that is the standard scalability story for most languages running on multiple hosts. However it seems deficient if one's goal is to make use of most of the cores on modern server hardware.

Last time I checked Node.js was not able to invoke fork.

Scalability, eh? What about that whole "scale beyond a single CPU" thing. I hear it's quite the rage.

I won't speak to his other points, however if all the author met was a bunch of "me too" douchebags, then the author clearly hung out with the wrong people. To meet the real san francisco tech scene come to a scrodeo: http://scrodeo.com/.

Same shit was happening to me for a while. I have 1 word for you: modafinil.

Offtopic, but am I the only one who finds it incredibly annoying when blogs like this disable the back button by overwriting the last item in your history?

A shot across the bow of 10gen?

Also I'd like to add that you should mention the name of the dev group. What they're doing is certainly shady, if not completely unethical.

I know you think your idea is the best invention since alcohol, but it probably is not. Given the choice between a half-assed execution of your awesome idea and finding the right person who can execute any idea I would choose the latter.

This article comes to an incorrect conclusion on the need for timeouts in Erlang's gen:call implementation. Monitors are necessary but not sufficient for building a robust distributed system with Erlang.

When dealing with remote processes a monitor is very quick to detect a process crash, however it can take a lot longer than 5 seconds to detect a node crash or other form of netsplit. Setting an application specific timeout in this case can be a prudent strategy for setting up a firebreak so that a netsplit does not cause cascading failures through the whole distributed system.

A case can also be made that just using monitors is not sufficient when talking with local processes. Monitors do not detect those situations when a process becomes unresponsive due to overloads like queue overrun. Once again it is a good idea to have a timeout in the call so that one may avoid a single misbehaving process crashing the whole system.

In fact, I find it difficult to imagine a situation where one would not want to have a timeout on a gen:call. That is why timeouts are set by default in the gen call facilities. Building highly concurrent systems is difficult. Erlang makes a lot of the typical pain points in building these systems go away. But the need to tune defaults and stress test a system remains.