https://www.statista.com/statistics/793628/worldwide-develop...

That's why we need to file a petition with the US Patent and Trademark office.

But that is not at all my point. The point is that google.com web properties have access to an API and a browser capability that is not available to it's competitors. Google only allows reading CPU info for itself.

The reason the data is not available for everyone, is because it would be a huge tracking vector. Same reason we don't allow webpages to read the device hostname, or username, or Chrome profile name. Google exposes this to google.com because it trusts itself. That poses this antitrust issue though.

The Google infra that we do use in this hot path (GFE via Google Global External Load Balancers, and Colossus via Google Cloud Storage) is the same infra that powers serving static assets for Google internal services.

If we were to provide an SLA (an agreement, stating the minimum level of service to a customer) for this service, it would not be 100%. It would be 99.99%. This is to avoid risk. But we can still have a higher internal target than the provided SLA.

If we have to make all changes in a way that requires that we do not even have 8 seconds of downtime a year (but 0 seconds of downtime), that significantly changes how you design a system and roll out changes.

TLDR: SLA != SLO

Also, a lot of the work that the registry does (parsing source code, analyzing dependencies, enforcing rules on the code, etc) are pieces of code that are shared with the Deno CLI, which implements this in Rust. The reason for this is that this work has to happen in Rust, because JavaScript, for the most part, can not "self-host" itself (ie you can not implement a JavaScript runtime on a JavaScript host if you want your runtime to provide more system bindings than the host runtime).

Finally, we do use Deno for many pieces of the registry where the "circular dependency" problem is not relevant. Namely the entire frontend uses Deno and Fresh :)