Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we built JSR

deno.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: How we built JSR

#21

Post by hagbard_c »

mike256 wrote: post #4

Why JSR (Java Specification Request)?

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.

   Flags: none
   Addressing Mode: absolute
   Opcode: 20

 [1] https://en.wikibooks.org/wiki/6502_Assembly

Re: How we built JSR

#22

Post by mxuribe »

internetter wrote: post #3
vladev wrote: post #2

Interesting that they use Rust for most things, rather than Deno. I would've expected more dog-fooding on their part.

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.

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. :-)

Re: How we built JSR

#24

Post by internetter »

lionkor wrote: post #17
paxys wrote: post #12

Earlier quoted context omitted.

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.

I would if you said your goal was 1M and you made 999,999

Re: How we built JSR

#25

Post by lucacasonato »

lionkor wrote: post #11

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.99…

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

Re: How we built JSR

#26

Post by lucacasonato »

Thaxll wrote: post #16

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.

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.

Re: How we built JSR

#27

Post by guilherme-puida »

mxuribe wrote: post #22
internetter wrote: post #3

Earlier quoted context omitted.

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.

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 m…

Common Lisp, maybe?

Re: How we built JSR

#28

Post by it »

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?

Re: How we built JSR

#29

Post by sshtml »

mxuribe wrote: post #22
internetter wrote: post #3

Earlier quoted context omitted.

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.

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 m…

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

Re: How we built JSR

#30

Post by lionkor »

lucacasonato wrote: post #25
lionkor wrote: post #11

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.99…

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 target…

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 :)
Post reply on HN