mattsoldo

It's never OK to physically attack someone like this. Full stop.

Separately; Sam's belief that "AI has to be democratized; power cannot be too concentrated." rings incredibly hollow. OpenAI has abandoned its open source roots. It is concentrating wealth - and thus power - into fewer hands. Not more.

“ It is named after one of its developers, Dick Pick.[2][3]” you can’t make this stuff up!

This sounds like an incredibly foolish expedition. They took a boat to sea without practicing basic seamanship procedures (person overboard drills), an inaccessible life raft, and no practice as a crew. That’s not adventurous, it’s reckless.

Money helps, but it's neither necessary nor sufficient.

I've been at a company that many considered to have excellent design and that received a lot of attention here (Heroku). There was a culture that permeated the company around beautiful design and what I would call "maker excellence". It was a place where people who liked building great things (both engineers and designers) felt at home.

Project Hail Mary by Andy Weir (author of The Martian) goes into the relativistic effects as well, and it includes a crazy (made-up) fuel that could make it possible. Great easy read: https://www.goodreads.com/book/show/54493401-project-hail-ma...

Thanks for posting the PG wealth tax article. It is a highly flawed analysis.

First wealth appreciates over time. So if your wealth appreciates at 15% / year, and the govt. taxes it at 1%, the net effect is growth rate is slowed to 14%. With these assumptions, someone starting with $1mm in wealth ends up with $2.6 billion after 60 years!

Second - PG ignores that most wealth tax proposals have a high minimum wealth - in the $50mm range. So there is no early compounding of the tax. Adding this into the model, the wealthy founder ends up with $3.3 billion after 60 years.

With no wealth tax, this hypothetical founder ends up with $4.3 billion. So, yes the government has taxed a total of ~ 25% over 60 years, but the founder ends up quite wealthy.

Yes, that is the correct term.

Is it the longest known exposure ever, or longest ever with a beer can?

Plus of the 10% of the shares soldo, most were to institutions with an understanding that they are going to hold it "long term" (i.e. which may be just a few months). Part of the IPO road show is for the company to select investors that believe in the company and who will be "good" shareholders.

It is a misconception that when a company IPOs and the stock pops, that the delta is money left on the table. The vast majority of the shares are sold to institutional investors. There are explicit or implicit lock-up periods in place. And most of the pre-IPO investors will typically have a 6-month lockup. So if 10% of shares are sold in the IPO and 10% of those shares are actually trade-able, only 1% of the total stock is liquid. That can lead to very large price swings (i.e. the pop).

PM for GCP buildpacks here, AMA.

This isn't the correct way to model wealth tax's effect on founder equity. Paul's model doesn't account for the changing value of equity over time.

When a startup was at the seed stage and worth say $5mm, a founder with a 50% stake would be paying $25,000 / year with a 1% tax. If the company grew and received a b-round of investment valuing it at $150mm, with the founder diluted to 20% ownership, the wealth tax on the $30mm in equity would be $300,000. As you can see the tax rate changes over time significantly.

There would likely be some unexpected consequences. Founders would re-consider sky-high valuations during funding rounds because of the effect on their tax rate. Startups may consider generating real cash-flow earlier on in order to issue dividends to their shareholders to cover the wealth tax instead of selling shares. If equity holders did sell shares to cover the tax, there would be a more liquid secondary market, which could make "house-of-cards" startup more apparent early on.

I was expecting URL parameters "Famous_company" and"Hyped_technology" to substitute in the text.

I saw someone do this with the plug to a laser printer once. The toner literally exploded in his face when he plugged it in.

I'll post the example source code here tomorrow after the talk (still tweaking it).

I'm doing a talk at Next tomorrow about just that. For now you are probably better of using Ruby on App Engine, assuming you need to use redis as a cache. Another new feature that we launched today is VPC Connectors, which allow Cloud Functions and App Engine to connect to servers/services in a VPC.

Cloud Run will have support VPC Connectors soon (it is supported, we just haven't wired up the API/UI). After that, its your choice, they run on similar infrastructure so you just need to decide if you want to live in containerland or source code land.

Spoiler alert. Sign up for the alpha by requesting to join this Google Group: https://groups.google.com/forum/#!forum/appengine-standard-r...

Hi. I manage App Engine (the original "serverless" product at Google).

This is a very understandable concern, given the importance of having a platform on which you can rely.

Contractually Google Cloud provides a 1 year notice before discontinuing (or making backwards incompatible changes) to products. This is for generally available (GA) products. Cloud Run is in beta, so technically it could be decided not to bring it to GA. This is why some conservative orgs tend to wait for products to be GA before releasing them.

From a technical perspective, Cloud Run was designed to be highly portable and idiomatic. If the service were discontinued (or you just didn't like it), you should be able to take your container image, and run it anywhere else. Odds are you would be using some other Google Cloud Services, so you would likely want to run in an environment with low network latency to Google Cloud (Compute Engine and Kubernetes Engine being obvious candidates).

From a historical perspective, I'd say that Google Cloud goes above and beyond in supporting older products. App Engine is about to hit its 11th anniversary. We are still running PHP 5.5 apps and backporting security patches to the runtime, despite the language losing community support 3 years ago. We are still turning down an old product called "Managed Virtual Machines", which has now been in a deprecated (but running) state for longer than it was GA!

From an emotional perspective, I think that Google is eyed with a lot of suspicion for turning off products. Google Reader - enough said. But as someone on the thread pointed out, Google Cloud is a very different business from the rest of Google. Google (!cloud) is a consumer company at a scale where if a product matters when it hits a billion users. Google Cloud is an enterprise company. Scale still matters, but not in the same way it does in consumer.

I can't wait for hacker news folks to try Cloud Run. Its an awesome product.

Hi. I'm the PM at Google Cloud on the Second Generation runtimes.

This is based on gVisor (https://github.com/google/gvisor), but it does not use the ptrace sandboxing that is in the mainline open source project. Our First Generation runtimes (aka nacl) were based on ptrace. In our informal testing we have observed the Second Generation runtimes to be about 20% faster than the First Generation. I don't have benchmarks on how it compares to a raw VM.

These new runtimes are capable of multithreading, so long as the language is capable of it. And you will need to use an instance larger than the default (F1 / B1) to have access to more than one thread.

It isn't limited to functions. Knative can run containerees, or with a build system take full app code and deploy it as a container.

Another PM on App Engine here.

Historically supporting a language on App Engine required modifying the languages libraries to work on proprietary parts of Google infrastructure. This entailed a decent bit of effort on our part, and also meant that some apps & code wouldn't execute correctly.

We now use technology based on gVisor (https://github.com/google/gvisor) in production for App Engine standard. This allows us to release new language runtimes unmodified. Node.js support is the first runtime based on this new stack.

We completely agree that we should be releasing support for new languages & major versions more frequently...

Countersue the doctor. Unfortunately without a suit to conterweight theirs, they only have upside.

And file a suit against Yelp.

+1. The inability to invest against startups and other privately held companies seems like a big economic inefficiency. It would be a counter force to these sorts of nose bleed valuations.

It's possible. The Apple Newton is a great case study of a good idea that was too early. And the inability to minitiarize it sufficiently to fit in a pocket was one reason for it's failure. A few years later the Palm Pilot was much more successful because it could fit in your pocket, especially the baggy jeans that were fashionable in the late 90's.

Webvan's model hasn't yet been validated. The local delivery startups and offerings are still losing lots of money. If anyone can make it work it will be Amazing, but it has yet to be validated as a profitable business.

This is great evidence of the greater fool theory: https://en.wikipedia.org/wiki/Greater_fool_theory

I’ve heard some second hand anecdotes about Magic. Apparently they have one big technology advance, which is that they’ve solved the eye tracking and vertigo challenges of AR. These are hard and not to be underestimated. However the company is supposedly a mess internally - with huge management and political issues. This isn’t surprising - I’ve been in a number of early stage startups and by default they are a mess. Add on top of that billions of dollars of funding and no customers or sales to anchor the company to reality, and its easy to see how AR can become “Alternative Reality”! Further evidence - their recently released headset photos were renderings, not actual products. I genuinely hope that I’m wrong - I’d love for the amazing demo videos they’ve released to congeal into real mass market products.

Does anyone else have good data on Magic?

This article states that former employees are "lining their pockets" at the expense of current employees who are "build[ing] future shareholder value" (i.e. creating value for VCs). But it ignores the fact that those former employees already built shareholder value when they were working. And by joining early on they took a much larger risk than employees who sign on during the growth stage - often receiving less salary and certainly holding more uncertainty over the future value of their equity.

A longer exercise window is a benefit that accrues to all employees, because it applies to all of them.

The author's proposed solution feels quite absurd to me - to prevent exercise of stock options by any employee who departs for a liquidity event. I wouldn't join a startup that had these provisions.