geoffschmidt

The architecture is designed specifically to support your choice of backends. The Meteor client and the Meteor server speak a simple JSON-based protocol called DDP. A Meteor client can talk to any server that can speak DDP. A Meteor server can talk to any client that can speak DDP. In fact, clients can connect to multiple servers by calling Meteor.connect() to open additional connections.

We already have a demonstration DDP client that is written in Python :)

My prediction is that in the future, you'll often see a breakdown where the user interface team works in JavaScript, and some of their code runs on the client, and some on the server. Other teams will build backend services in whatever language is best for the job, and they'll talk to the JavaScript written by the UI team (sometimes interfacing directly on the client, and sometimes, for example when multiple services are integrated, going through some JS code on the server.)

That's just a guess though.

It's always a good idea to separate business logic from presentation logic. The idea in Meteor is that your business logic can run on either the client or the server as is appropriate in a given situation. For example, if you want to get the most recent 10 posts in the news feed, the exact same line of code works on both the client and server. Why have two APIs for this when you could have one? Of course the server still has to make sure that clients can't read or write to records they shouldn't (cf point 6, "Sensitive code runs in a privileged environment.")

Meteor has brand-new experimental support for serving HTML to crawlers. Check out the Google cache for meteor.com :) The links work and everything. This just went live this morning.

By raising this amount of money, we've (semi-deliberately) closed the door on any possibility of an acquihire. The valuation is too high for the VCs to agree to that outcome, and one of the privileges of Series A shares is the ability to veto acquisitions.

So we have two choices: (1) build Meteor into a great development platform, get a lot of people to build apps on it, and find something that we can sell to the operations department of big companies that are using it (I wrote a bit about this in other comments), or (2) fail.

IMO, this is dead on.

We group your first two requests together as a project called Routes, and it will be one of the big initiatives we take on once the authorization and account work is shipped to production.

As for your third request, we're been careful with this. Internally, Meteor is already database agnostic. For example, DDP, the Meteor wire protocol, is based on tables, and all of the code that performs latency compensation, etc, doesn't make any database assumptions. Mongo support is provided by a Smart Package that includes the client-side Mongo emulator and the server-side Mongo connector. Supporting SQL, Redis, Couch, etc, is a "simple matter of programming." We'll likely do Routes first since there's more technical risk there.

While I was fundraising, VCs told me that DHH could easily have raised a lot of money for Rails had he chosen to. I don't know for sure that that's true, but it certainly seems plausible given Meteor's experience.

Even though we chose a different path, I really admire what DHH did with Rails. We studied the original Rails screencast very carefully when were making the Meteor screencast.

What they're dreaming of is: lots of big companies write their vital business apps on top of Meteor. They spend billions of dollars on middleware and application servers that helps them deploy, monitor, and control these apps across their 100 divisions and 5 data centers, similar to the billions of dollars they've spent in the past on Oracle, WebSphere, Tuxedo, Tibco, etc. Meteor does an IPO.

Failing that, they're hoping that we can replicate the success of JBoss ($420M to Red Hat), XenSource ($500M to Citrix), or SpringSource ($420M to VMware), all of which took open source software and sold it to the enterprise, and each of which did it under the direction of one of Meteor's new advisors (David Skok, Peter Levine, and Rod Johnson respectively.)

As for time frame, they are patient and expect it to take a long time. They know that it takes years for a platform to be adopted.

Here's what I learned when doing this research for Meteor.

* You can sell training, but it's low-margin. If that's all you do, it probably ends up looking more like a consulting business, because you have to recruit armies of teachers if you want to scale up the business.

* You might think you can sell support, but it's hard. There's a catch-22. If your product is good enough that people want to use it, it's probably good enough that they don't use their support incidents and end up not wanting to renew their support contracts.

* You can sell some kind of management software or application server that only big companies need. This has been a sweet spot for some other projects. Developers at small companies don't have any money, and developers at large companies don't have any budgetary authority. But, the operations teams at larger companies have a budget, and if you have an offering that's useful to them, they're able to pay what it's worth.

* You can sell long term maintenance of other people's software. This is the Red Hat model. They put their LTS stamp of approval on a collection of packages, and guarantee that those packages will be maintained for N years. People will pay for this. The investors I talked to seemed wary about this model. "Yeah, Red Hat got to $1B of revenue, good for them, but man, it took a long time."

* Platform-as-a-service is harder than it looks. Small customers will pay incredibly huge markups. But that's only if you look at it on a percentage basis, rather than in terms of absolute dollars. When someone gets big enough to be paying you "real money," they tend to leave your PaaS, either because it's too expensive (it becomes financially reasonable to pull the function in-house) or because you don't give them enough control or security.

* If you make your software GPL, you can extract a few million bucks from big companies that can't use any GPL software, which sometimes happens for complicated reasons involving, eg, patent cross-licensing deals. If your software is truly universal and something that every developer must have, they will write you big checks for GPL exceptions. But these are one-off deals and you can't really build a business on them.

Interesting point, but if that is their thinking, they didn't share it with me :)

As far as I know, they're looking the billions of dollars a year that IBM makes on WebSphere and thinking, "all of this spending on middleware and applications servers, where is it going to go in the future, if the future is client-side JavaScript, native mobile apps, and other things that fetch data over the wire and render it locally?"

They're hoping that in the fullness of time, many corporations will build important apps on Meteor, and that when those apps go to production we'll get a slice of their operations budget. It's the same model as the relational database.

I think that's a great idea. The ability to do creative things like this is the "silver lining" of having so much money in the bank (which, as I mentioned above, is something I generally consider a risk, or at best a hedge.)

I'd love to hear your ideas about how this could work, and when we should start doing it (it's probably way too early?) either here or on meteor-talk.

As the guy that raised the $11M, I agree completely. It is terrifying and a huge risk.

IMO, the biggest downside to raising a lot of money is that you are no longer accountable to anyone. You can run around saying "We're rockstars! We're winners! Catered dinners! Aeron chairs!" for years, even if you make no progress and produce nothing of value. At least if you stick to the "right" cocktail parties.

untog, I'm counting on people like you to call us out if we get slow, fat, stupid, lazy, and arrogant. Ultimately, we will be measured by what we ship, or better, what other people ship on top of Meteor.

Hi, I'm the OP (or at least the author of the blog post.)

I should have been clearer. Most of the core devs have side projects that they're building on Meteor. I'm building a social contact manager, which I'm using for a community group I'm involved with. Nick built an app to keep a database of his wedding guests. David built a app to keep track of the schedule for his favorite TV shows. Matt has built some games.

What we're not doing is trying to turn any of these other projects into businesses. Meteor is the reason we exist, rather than something that we have to continually justify to ourselves as an "engineering investment" as we build our "real" product.

You're exactly right, it is poison to try to build any kind of API without having some motivating use cases in front of you. So one of our rules is, we try not to add any feature to the framework without having seen people implement it several times "by hand" in the app. Then we try to find the common bits between those implementations, polish them until they shine, make it accessible to a new JavaScript developer, and finally package it as an optional Smart Package.

So far, every feature in Meteor has been built to scratch an itch that we had while building actual apps in Meteor. For example, the reactive templating system was originally built to make the meteor.com homepage easier to build. The new auth/accounts package is something we've all wanted for our weekend projects for months. And the forms/live templating overhaul that David is working on comes partly from the difficulty we had with embedding Twitter buttons in the meteor.com homepage app, and partly from the large amount of boilerplate code that I had to write in my social CRM.

Finally, there actually is one fully-scaled commercial app that we'll soon be building on Meteor, and that's the web interface that'll let you manage your deployed Meteor apps and share them with other team members (if you choose to use our "meteor deploy" servers.)

More succinctly, if you're able to build a $20M business on a $250k investment, the money to build the business came from your customers -- you've used customer financing, which Chris described in his blog post as the most desirable form of financing.

Chris is not talking about this. He's talking about venture capital, where (1) you typically need to raise at least $2M (otherwise the firm can't justify the board seat), (2) the money for the investment came from a venture fund that was raised from limited partners, and the fund's lifecycle is structured such that the investments need to see liquidity within 5-10 years.

As for angel investors, the angel deals you hear about on HN and TechCrunch work differently from what you're talking about. They don't buy common stock and they wouldn't receive dividends even if you paid them. Instead the angels receive a debt instrument that turns into series A preferred stock once you raise venture capital. If you fail to raise venture capital, the angel writes off the investment as bad debt and walks away. Historically these deals wouldn't even fix a value on the company, though the conversion caps that are now in vogue are effectively valuations.

One reason it's done this way is that just the legal fees for issuing series A preferred stock easily run to $50-75k. That money is spent drafting the protective provisions that make the stock "series A preferred" rather than "common". Another is that, historically, angels have found that the big wins are so big that they make the rest of the portfolio irrelevant.

So sure, if you can find an angel that will buy $250k of common stock in a tech company that has no chance of a big upside, go for it, but I think you're going to be looking for a long time. Of course you're right that many businesses are financed through small common stock deals, but these are more often small businesses like your local restaurant or auto mechanic, where the business model is well understood but there is no chance for this 10x return on capital you mentioned, and the money usually comes from friends and family, not from professional investors.

Though it's none of our business, it's also not an assumption :)

http://postcards.blogs.fortune.cnn.com/2012/07/16/mayer-yaho...

> Mayer first disclosed to the Yahoo board that she is pregnant in late June, in a meeting with Michael Wolf, a member of the board's four-person CEO search committee. A meeting with the search committee followed, and then Mayer met with the full board last Wednesday. None of the Yahoo directors, she says, revealed any concern about hiring a pregnant chief executive. "They showed their evolved thinking," says Mayer, who got the phone call last Thursday that she was the board's choice to be CEO.

Burning Man. Join a theme camp and work on a big project for three months with 50 people, then try to survive the dust storms together on the playa. It's a great way to make friends. I'm told that you can have a similar experience working on a Mardi Gras float in New Orleans. There must be other regional equivalents.

Since you apparently get the full $7500 regardless of how much your vacation costs, what he's effectively doing is docking everyone's pay $7500 if they don't take at least one fully disconnected vacation a year.

While this is an excellent point and one I hadn't heard before, I'm not so sure you're properly modeling the cost of maintaining other currencies. Must we include the Fed? The enormous physical system that securely moves money all the way from the mint to every single cash register? The opportunity cost of the time of all of the smart people who work on international currency arbitrage, but would otherwise be doctors and scientists?

Since paper money is backed ultimately by the threat of violence against those who counterfeit it, wherever they may be in the world, we must include some fraction of our defense spending as well. In fact, the more valuable the currency, the more must be spent on defense to protect it. Isn't this closely isomorphic to your dichotomy?

It's not rent control that keeps SROs around - there are separate SRO controls. You're not allowed to eliminate SRO beds without building replacement beds in another part of the city (or paying into a fund to cover the cost of someone else doing it, and it's a significant fee.)

Many of the people in SROs have substance abuse or mental health problems or other disabilities, and most (?) SRO tenants are paying their rent in federal housing assistance vouchers (which is why SROs can be so profitable - the government pays you a high price to house people that otherwise wouldn't be welcomed on the rental market, housing discrimination laws notwithstanding.)

Any zoning plan has to make space for this population somewhere in the city. If you let people demolish SRO beds, you're just going to discover that you have to build new ones at public expense.

Do you really think the main constraint on supply comes from rent control and not zoning limitations? In SF there is a strong desire to preserve the historical character of the neighborhoods (agree or disagree as you like, but the political will is there) and I think that's the root reason why it's difficult to demolish buildings and rebuild them with more units, not the mechanics of rent control.

In any event, even in a rent controlled building, you absolutely can terminate all of your tenant's leases and kick them out, upgrade the property, condoize it, and sell the condos (Ellis Act.) The only restriction is that you must sell the units, not rent them.

(speaking as someone who, as a side project, is in fact building high density residential units in SF)

No, unfortunately refunding the deposit doesn't necessarily clear him of liability. If I say I'm going to do something, and I don't, I can't always get out of the situation by saying "let's pretend I never made a commitment."

That said, I doubt it's as bad as he fears. He needs a lawyer.

Direct link to petition: https://wwws.whitehouse.gov/petitions/!/petition/require-fre...

It only takes a minute to sign :)

Most political petitions have no impact. They are just email-gathering campaigns. This one is different: it's on the Whitehouse site and it's not for gathering emails, it's to give Open Access advocates some political cover as they craft their proposal.

So if you sign only one online petition this year, make it this one.

I think she's thinking logically. From the perspective of a RelatRides lessor, fatal accidents are low probability events. That she experienced such an event yesterday doesn't change the probability that she'll experience such an event tomorrow. She's only naive if every single RelayRides lessor who reads this story is also naive to continue using the service.

Placebo coupons -- isn't this essentially what drives Farmville's virality?

I wish I could think of a reasonable way to normalize for the age of the company. A decade ago, there was no SOX and it didn't suck as much to be a public company, and it wasn't as easy (?) to raise $100MM from DST as an alternative. Facebook delayed its IPO for as long as possible and went to the private capital markets instead of to the public. Its valuation should be compared with companies at a similar point in their lifecycle.

This doesn't show the compiled code, it shows the syscalls that are made by libc and the dynamic linking system to set up the process.

Back in the days of a.out and static linking, it was much shorter and easier to understand.

I meant the synthetic memory arena, the JS array that malloc() and free() manage. That certainly could contain JS references and needs to be examined by the GC.

I don't think you can actually avoid GC by avoiding JS object allocations. Any form of string manipulation, any form of IO (event handling, DOM manipulation, XHR), any use of timers, etc, is going to allocate objects, right? Also, the JS runtime could generate garbage internally. For example, since JS has closures, it wouldn't be totally unreasonable for the runtime to manage the lifetime of activation records (JS stack frames) using the GC.

Why does malloc take a byte count, just to divide it by sizeof(u32)? Why not embrace the fact that natural "word" in the JavaScript VM is a boxed value that stores an int, float, or string, and define sizeof(u8) === sizeof(u16) === sizeof(u32) === 1? Unless you really want each cell in your memory arena to literally emulate a byte and always store a value between 0 and 255?

In a similar vein, why not use the native JavaScript object type to back the structs? This will cooperate nicely with the inline caching in typical JavaScript JITs. The result will be native assembler that indexes directly into the structs in the way you'd hope, since your static typing system forces every object reference to be monomorphic.

Does this language actually eliminate GC pauses? Isn't the GC still going to run, except now it has to walk every single cell in your memory arena every time, defeating the very heuristics that GCs use to reduce pauses?

There's definitely something alluring about the static typing, but I'm less sold on the manual memory management. Maybe there is a way that the language could help you generate less garbage, without actually requiring you to manually control the lifetime of each object?

From your linked-list example, it's eminently clear that it needs a C++-style template system and a port of the STL :) If you wrote a C-to-*JS translator, you could hypothetically use a pre-existing cfront (C++-to-C translator) and STL implementation to get that working.

It's hard to evaluate your claim that ExtremeTCP is "the" solution, given that your website (1) does not compare your solution to the significant amount of literature and prior art in this space (eg, TCP Vegas, which is already implemented in the Linux kernel), (2) doesn't make any claims about friendliness to TCP Reno, which is the hardest part of retrofitting a new congestion control strategy onto the public Internet.

It's like you haven't even seen The Social Network.