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 :)
Aside though: IMO python is good as "glue" between low level code. JS... I don't know man.
It sounds like they use Fresh (deno framework) for the web ui parts.
JavaScript for UI, Rust for data
How do you manage 100% uptime when your db is only going to be 99.9%? The latter is almost easy, the former, even if we assume 99.99999%, really really hard.
Just silly and may show that there are some unrealistic assumptions, maybe? Or maybe the team doesn't know much about reliability -- also concerning.
Just target six nines and be done with it, or something.
In may of last year, NPM was down to 99.8 for the month.
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
6800: http://www.8bit-era.cz/6800.html
6502: http://www.6502.org/tutorials/6502opcodes.html#JSR
PDP-11: https://programmer209.wordpress.com/2011/08/03/the-pdp-11-as...
Motorola 68000: https://mrjester.hapisan.com/04_MC68/Sect05Part05/Index.html
Jumps to a subroutine
The address before the next instruction (PC - 1) is pushed onto the stack: first the upper byte followed by the lower byte. As the stack grows backwards, the return address is therefore stored as a little-endian number in memory. PC is set to the target address.
Flags: none
Addressing Mode: absolute
Opcode: 20
[1] https://en.wikibooks.org/wiki/6502_AssemblySet
Radiooooooo
> The JSR API server is written in Rust, using the Hyper HTTP server. It communicates with the Postgres database via the sqlx Rust crate.
Looks like most of the backend is written in Rust. Must be a bummer working on a JS runtime, and not being able to test it out at such a scale.
It's trivial to see because when GCP is down somehow Google and Gmail keep working.
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.
I work at Google and even I do this. Services like the storage backing GCS are incredibly reliable and have teams of SREs supporting them, so I offload as much as possible to services that have more dedicated support than I'm able to provide.
According to "Latency Numbers Every Programmer Should Know (2020)" [1] reading even a single page from a modern SSD takes over 10 microseconds.
[1] https://colin-scott.github.io/personal_website/research/inte...
Interop with npm kills any benefit of using it until adoption is high.