snewman

Do you have a source for this? I don't think it played out that way. Google Docs and Sheets both had synchronous editing before Wave launched. At some point Docs was rewritten to use the underlying mechanism from Sheets. I'm not aware of any cross-pollination from Wave. The Docs and Sheets teams were fairly closely connected; Wave was developed in an entirely separate part of the organization, I believe the team was mostly in Australia, and there was never much communication AFAIK.

(Source: I was co-author of the original Google Docs implementation aka Writely; had some visibility into later iterations. I left Google in 2010 but have some idea of what went on subsequently.)

Air pressure, a few details aside, must be equal to the weight of the air molecules sitting above the spot where you are measuring it. If we add more gas to the atmosphere, sea level air pressure must increase. One way to think about it: the weight of the additional gas smooches down on the existing atmosphere, compressing it and thus increasing the pressure.

Of course all of this is academic in any event; addressing climate change by diluting the CO2 is a nice attempt at out-of-the-box thinking but it's not actually plausible.

This doesn't work. First of all, you'd still have the same mass of CO2, so the insulating effect wouldn't change. Those molecules would still be there to interfere with infrared radiation trying to escape into space.

Second of all, you're talking about gargantuan quantities of oxygen (or nitrogen, or whatever). CO2 is roughly 1/2500 of the atmosphere, so to achieve a given amount of dilution, you can remove one CO2 molecule or add 2500 other molecules.

Finally, I don't know what the side effects of increasing global air pressure would be, but I'm sure there would be significant effects!

> According to the EPA [1], electricity accounts for 25% of greenhouse gas emissions.

Yes, but realistic plans for addressing climate change generally entail converting a lot of other activities to electric power; this is on the table for everything from transportation, to heating + cooking, to steel manufacturing. Not to mention carbon capture; many of the options there require a lot of energy. Even if some modes of transportation continue to require chemical fuels, we may be using electricity to produce some of those fuels.

It's reasonable to quibble at the margins, but in the big picture, we are going to need a LOT of carbon-neutral electricity and that is going to drive a lot (the solid majority?) of greenhouse gas mitigation.

> The counterpoint is electric vehicles. While these are generally a positive, they have more limited utility, higher cost (a significant issue in much of the world) and you have to factor in the externalities of the power used to charge them.

What point are you making with regard to externalities? Everything has externalities, you just need to add them into your calculus. Are you suggesting the externalities of electric vehicles imply that we should stick to fossil fuels for transportation?

As for higher cost: cost should continue to come down as we continue to climb the learning curve. I don't know if / when the lines cross (and of course it will be different for different use cases and locations), but again - if we're going to address climate change, we don't have a lot of choices; we will have to find a way to bring costs down and/or subsidize the higher cost.

"Limited utility" is absolutely going to be an ongoing challenge, but again it's not like we're helpless to do anything about it. More charging stations, longer range, possibly adjustments to usage patterns. In some cases, yes, we might need to stick to chemical fuels and find carbon-neutral sources, but this is not ideal and my expectation+hope is that it will eventually be very much a minority of usage.

I should note, I'm not advocating for nuclear power as the source of all this electricity we'll need; the feasibility of scaling nuclear power is a complicated topic and personally, I honestly don't know what to think or expect. The point I am trying to make is that a BIG part of "how to stop emitting GHGs" is going to boil down to "how to generate a stupendous amount of carbon-neutral electricity".

Except that (presumably) there is no guarantee that any spot instances are available. You could wind up in a state where you have no instances running. No user-facing production service can tolerate that.

I imagine the reason they make so much from the store is that the gas station is drawing people in? It's expensive to build and maintain the gas station itself, they wouldn't do it unless it was an important contributor to the business model.

The problem here is not taxation, it's the artificially constrained housing supply in the Bay Area. Too many people are chasing too few houses; they would remain unaffordable to most even if the tax rate were zero, because prices would rise to match income.

I'm honestly baffled by this argument. Do you click through 100% of the links that reach the front page? More to the point, do you expect/desire that most HN readers should do so? Presumably not; so, we must expect that readers -- no matter how curious -- are exercising some decision algorithm. Why deliberately cripple the input to that algorithm? Shouldn't we trust readers to exercise curiosity even when provided with a good descriptive title?

It's a tradeoff.

In my view, the primary function of the title is to help a viewer understand whether the topic is of interest to them and therefore it is worthwhile to click the link. A more-informative title will better serve this critical function.

If some HN participants are prone to making off-base comments based solely on a title, let's address that directly (e.g. via guidelines + voting), rather than by nerfing the titles. Otherwise we're just throwing up our hands and saying "this is why we can't have nice things". I'd rather work toward having the nice things.

Incidentally, it's not just (or even primarily) about length; an article's "native" title often makes sense only in local context, and thus does not communicate well when seen out-of-context on the HN front page.

I'm not sure this follows.

It's a fair point that any easy-to-find bugs in large, time-tested contracts will have been found. Any medium- or hard-to-find bugs also will probably have been found. But there might still be a very-hard-to-find bug lurking; and given the value of finding such a bug, people might look hard enough to find it.

In other words, the same scale that ensures there is no low-hanging fruit, also provides the incentive to pick high-hanging fruit.

> I have a lot more trust in that kind of product than in a product where contracts are subject to interpretations by humans which may or may not be reliable.

This is a valid concern, but it's also extremely well-understood at this point; we have centuries of global-scale experience with traditional financial and legal systems. They're certainly not flawless, but it's rare for gigantic new flaws to emerge. An important point is the existence of mechanisms for rolling back bad transactions and challenging / appealing flawed decisions.

Human skin temperature is considerably lower. (Or to think of it from another perspective, the system which is insulating your core temperature includes layers inside your body – skin, etc. – in addition to clothing, blanket, etc.)

Thermal insulation, whether we're talking about a blanket, a winter jacket, or the foam stuff in your walls, generally involves a layer of some thickness within which there are many tiny spaces full of trapped air. It's difficult for heat to propagate across those spaces. The author's point is that mylar emergency blankets do not provide this thick layer of "trapped air". It's true that they prevent air from crossing, but only for the very thin layer of the blanket.

I'm not sure exactly how effective the mylar blankets are and under what circumstances, but this is what "trapped air" refers to.

Where do you get the $200 million figure?

Bear in mind that it is only the Starship (upper stage), not the Super Heavy booster, that would be landing at the destination and hence potentially subject to abandonment. Also note that Starship, unlike Falcon 9 (or at least to a much greater extent), is designed to be produced efficiently in quantity.

Whatever the issue, presumably it did not arise during testing. That seems to point toward something that would only happen on Mars... so, yeah, maybe radiation?

Yes, but in this case that was just good luck. As the article mentions, the low-altitude behavior is because of concerns regarding dust. It was not intended to provide robustness in the face of glitches in the optical navigation system.

A thousand times this. Best screwball comedy ever.

Also You Can't Take It With You. Now you've seen one Cary Grant and one Jimmy Stewart. To finish up you can get both of them with Catherine Hepburn in The Philadelphia Story.

Distribution. It is so, so, so much harder to get most users to install an app, especially for casual purposes ("please add your notes to this doc") which is often how people first come to Docs.

After leaving Google I founded scalyr.com. To get an idea of the type of work we're doing, this old blog post holds up: https://www.scalyr.com/blog/searching-1tb-sec-systems-engine....

Thanks!

The "floating workspace" aspect has always driven at least as much usage as the "collaboration" aspect. That came as a complete surprise to us, but it turned out to be very important to adoption. At some point I think we determined that the average document had something like 1.1 collaborators.

> With a canvas-based engine, the editor is no longer relying on the contenteditable spec right?

Correct. In fact, contenteditable went out the window a decade ago when the "#2" engine (low-level DOM manipulation) was launched.

My experience with contenteditable is ~12 years stale at this point, so the only thing I'll try to say is that I expect it would work well up to a certain level of ambition, and no further. As I say above regarding frameworks: they're great so long as your requirements fit within the expectations of the framework, but you quickly hit a wall if you need to stray outside of that. For Docs, the desire for a paginated view/edit mode was an example; there was simply no sane way of squeezing pagination into a contenteditable-based engine.

This is why I love HN. :-)

However, I can't claim credit (or blame, but I would argue mostly credit) for that code. There have been three generations of the Docs editor that I know of:

1. The original, which I was involved in, was an unholy mess perched shakily atop contenteditable. As such, it contained no layout or rendering code (but did all sorts of horrid things under the hood to massage the HTML created by the various browser contenteditable engines and thus work around various problems, notably compatibility issues when users on different browsers are editing the same document). Originally launched in 2005.

2. In the early 2010s, an offshoot of the Google Sheets team launched a complete rewrite of the Docs engine which did its own editing, layout, and rendering based using low-level DOM manipulation. This was more robust, supported layout features not available in contenteditable (e.g. pagination), and generally was a much better platform. My primary contribution to this effort was to incorrectly suggest that it was unlikely to pan out. (I was worried that the primitives available via the DOM would be insufficient; for instance, to deal with mixed-directional text.)

3. This canvas-based engine, which I learned about a few hours ago when this post popped up on HN.

I don't know whether #3 is an evolution of #2 or a complete rewrite; for all I know there was another generation in between. But I imagine you were looking at some iteration of #2.

I'd love to have a good answer for you, but I learned the basics all the way back in the '80s. Seems like I've seen references posted occasionally on HN, hopefully someone has a good link.

Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I'm seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It's been a long time since I've really been involved in browser coding, but having written both Writely and, farther back, several native-app word processing engines, here are some thoughts.

Word processors have extremely specific requirements for layout, rendering, and incremental updates. I'll name just two examples. First, to highlight a text selection in mixed left-to-right / right-to-left text, it's necessary to obtain extremely specific information regarding text layout; information that the DOM may not be set up to provide. Second, to smoothly update as the user is typing text, it's often desirable to "cheat" the reflow process and focus on updating just the line of text containing the insertion point. (Obviously browser engines support text selections, but they probably don't expose the underlying primitives the way a word processor would need. Similarly, they support incremental layout + rendering, but probably not specifically optimized in the precise way a word processor would need.)

Modern browser engines are amazing feats of engineering, but the feature set they provide, while enormous, is unlikely to exactly match the exacting requirements of a WYSIWYG word processor. As soon as your requirements differ even slightly from the feature set provided, you start tipping over into complex workarounds which impact performance and are hell on developer productivity and application stability / compatibility.

This is loosely analogous to CISC vs. RISC: browsers are amazing "CISCy" engines but if your use case doesn't precisely fit the expectations of the instruction set designer then you're better off with something lower-level, like Canvas and WASM. (I don't know whether Docs uses WASM but it would seem like a good fit for this Canvas project.)

Frameworks in general suffer from this problem. If you've ever had to fight with an app framework, or orchestration framework, or whatever sort of framework to accomplish something 5% outside of what the framework is set up to support, then you understand the concept.

Also, as noted in many comments here, browser engines have to solve a much more general problem than Docs, and thus have extra overhead.

In general in biology, when there is long-standing dispute as to whether a certain system relies on Mechanism X or Mechanism Y, my impression is that the answer almost invariably turns out to be that X, Y, and previously-unsuspected Z all play a role.

Now Flinging TEUs

It was fine if you were a kid (small hands)...

I take your point with regard to the economic incentives at play. But at the end of the day, it seems likely that the net effect of this article will be to drive more readers to the new Subspace blog? (A sort of Streisand effect.)

Correct.

Per Wikipedia:

> In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in a way that memory which is no longer needed is not released.

In most of your scenarios, e.g. "pushed to some queue", the object in question is still needed. Hence, this is not a leak. Presumably, the entry will eventually be removed from the queue, and GC will then reclaim the object.

At any rate, I think we're moving past the point of productive discussion. My experience in practice is that memory leaks are more common / harder to avoid in non-GC languages. Of course a true memory leak (per the definition above) is possible in a GC language, but I just don't see it much in practice. Perhaps your experience is different.

But it's much easier to forget-to-free:

  Foo* foo = new Foo();
  ...code that uses foo...

This is a memory leak in a non-GC language, but not in a GC language.

In a practical sense... is it your personal experience that memory leaks are equally prevalent in GC and non-GC languages? I've spent decades working in each (primarily C++ and Java, but also Pascal, C, C#, Smalltalk...) and my experience is that memory leaks were a _much_ bigger issue, in practice, in the non-GC languages.