How we built JSR(deno.com)
deno.com
How we built JSR
https://deno.com/blog/how-we-built-jsr
40 comments
Interesting that they use Rust for most things, rather than Deno. I would've expected more dog-fooding on their part.
So the reason we do this - and I should have mentioned this in the post - is that we explicitly do not want to dog food here. Because JSR is the package registry, if it goes down, and we can not pull packages from the registry during deployment of a new version of the registry (that fixes the reason it is down), that would be very bad. So we don't put anything that depends on the registry in the path of deployment of the registry :)
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 :)
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 :)
Deno is written in Rust, so it makes sense to write stuff like Typescript compilation in the same ecosystem as your Typescript runtime.
It sounds like they use Fresh (deno framework) for the web ui parts.
JavaScript for UI, Rust for data
It sounds like they use Fresh (deno framework) for the web ui parts.
JavaScript for UI, Rust for data
Not really. Most software nowadays is like When I pay it is Rust for best performance when user pays(in perf or actual dollars) ..blah..blah.. JS/Electron for the win
The Javascript and Python ecosystems, somewhat ironically, have begun using rust for their tooling, because the actual language is too slow.
Aside though: IMO python is good as "glue" between low level code. JS... I don't know man.
Aside though: IMO python is good as "glue" between low level code. JS... I don't know man.
My dream language/environment would be something that is ubiquitous, has a straight-forward learning curve, has a REPL, and empowers dev productivity - like python - but then, if i should choose, there would be an additional straight-forward path for me to push my code thhough some compilation process in order to supercharge the performance/speed of my code - like Go or Rust, etc...Basically let me choose to employ my code as a (dynamic) script, or compiled code...sort of like some hybrid of python and Go, or python and rust, etc. but combined into a single lang./env. :-)
That's Java. You can work in the REPL, and when you put your code in a file and launch it it runs fast; very fast.
I can't deny the performance and scalability of Java. But I've never been a fan of the need to be so verbose when coding for it. Also my memory of Java is from the late 90s...so maybe I'm missing something but I can't recall there ever being a REPL in Java. So I guess TIL :-)
Not only is there now a REPL, but the language is not at all what you remember from the 90s.
That is what Scala claims to be. https://www.scala-lang.org/
Scala has its own downsides tho. It is a "big" language in the sense that because it tries to do everything, there are too many ways to do one things.
Scala has its own downsides tho. It is a "big" language in the sense that because it tries to do everything, there are too many ways to do one things.
Common Lisp, maybe?
I believe this is essentially the goal of Mojo [0][1], at least for ML/AI development.
[0] https://www.modular.com/max/mojo
[1] https://news.ycombinator.com/item?id=35790367
[0] https://www.modular.com/max/mojo
[1] https://news.ycombinator.com/item?id=35790367
Another rabbit hole for me to discover! Thanks!
Why JSR (Java Specification Request)?
Jump to Sub-Routine?
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
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
Jump to New Location Saving Return Address: JSR [1]
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.
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_AssemblyJet
Set
Radiooooooo
Set
Radiooooooo
JavaScript Registry
Hey hey, post author here - happy to answer your questions!
I'm not sure what 100% uptime is supposed to mean. Zero downtime, thats like saying zero bugs - it's not going to happen. Even 99.9999% uptime would be realistic, but 100% is not happening. There are factors out of your control that you cant guarantee will not even be down 1ms per year.
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.
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.
The SLO (objective) is an uptime of 100%. That means that we have no error budget to use for scheduled maintenance or anything of that sort. This means that we can not use software in this hot path that would require scheduled maintenance (ie a relational database that requires periodic downtime for major version upgrades). We additionally minimize risk here: no code that is written by us sits in the path that targets 100% uptime. Ie if it breaks, its due to an upstream failure within Google's web serving infrastructure.
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
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
Hi, that makes sense, thank you - I didnt realize that this was meant in terms of "we have to choose technologies that never ever have to have maintenance", that would have been a better way to put it. Thanks :)
It's a goal, not a guarantee.
Yes, but it means nothing. If the realistic version of that goal is 99.99%, thats not very good at all.
You wouldnt applaud me if I said my goal total comp was 1M, and then i went and got a job that pays 30k.
You wouldnt applaud me if I said my goal total comp was 1M, and then i went and got a job that pays 30k.
I would if you said your goal was 1M and you made 999,999
> So how do we make serving modules reliable? We defer the entire problem to Google Cloud. The same infrastructure that serves google.com and YouTube is used to host modules on JSR. None of our custom code sits in this hot path
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.
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.
Am I the only one here who saw the title and had hoped it was a post-mortem for Jet Set Radio? :)
My disappointment was inconsolable and my day ruined :(
Curious how you’re implementing the background queue for publishing? Something custom in Rust?
It uses Google Cloud Tasks
Just a small point but google.com and YouTube do not run on the same infra as what you see on GCP, especially if you use GKE etc...
It's trivial to see because when GCP is down somehow Google and Gmail keep working.
It's trivial to see because when GCP is down somehow Google and Gmail keep working.
We do not use GKE.
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.
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.
Deno continues being everything: now additionaly it is package manager, cdn, and package registry.
Interop with npm kills any benefit of using it until adoption is high.
Interop with npm kills any benefit of using it until adoption is high.
I'm making an app with a Typescript+React front end and a Go back end. While in local development, I serve it with Vite. Could I use Deno in place of Vite+Node?
It was just a search away. https://docs.deno.com/deploy/tutorials/vite
> We use the excellent sqlx Rust package to handle migrations.
> 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.
> 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.
The V8 engine is written in C++ not JavaScript. Building high-level languages/tooling in lower-level system languages is a very common (and sensible) practice.
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...