3 ms·

I like a lot of what Deno does, but I'm having some trouble understanding why this (along with Deno's KV and Queues offering) is part of the Deno runtime. The

I like a lot of what Deno does, but I'm having some trouble understanding why this (along with Deno's KV and Queues offering) is part of the Deno runtime. The blog post touts this as a feature to reduce the amount of code to get up and running, but a library would accomplish the same thing. A first-party library could even directly integrate with Deno Deploy in the same way that this appears to. Why pollute the runtime with something unrelated?

gangstead 3y ago
I think Ryan Dahl (creator of Deno and Node before that) is trying to make it stand out from Node which has a very small standard library. So they are including common things that used to be in many separate modules.
ramesh31 3y ago
>Why pollute the runtime with something unrelated? Because money. They are venture funded and need to show some kind of path to profitability.
- imbnwa 3y ago
  People acting like Bun, which is also ventured funded, isn't going to be doing a lot of similar things once they stabilize their runtime. Node had a lot of runway in the era/climate it was made in.
  - ramesh31 3y ago
    I also get the sense that Dahl ended up feeling slighted about his loss of control (see: ability to extract rent) of the Node ecosystem, and doesn't want to let that happen again. It feels almost quaint how open things were back then.
    - imbnwa 3y ago
      Interesting, didn't know that was a background intention
elbasti 3y ago
What makes jobs "tricky" is that jobs are--by definition--entirely side-effects. So: - What happens if the process where you called the job crashes? - What happens if the entire application crashes? - What happens if two threads/processes schedule the same job? - Should jobs be stored in memory? On disk? In a db? Are all sort of interesting questions. Presumably the Deno runtime deals with this in a way that's opaque to the user, but that using "a library" does not, especially in a language like Javascript where processes/jobs are not really first-class.

gangstead 3y ago

I think Ryan Dahl (creator of Deno and Node before that) is trying to make it stand out from Node which has a very small standard library. So they are including common things that used to be in many separate modules.

ramesh31 3y ago

>Why pollute the runtime with something unrelated? Because money. They are venture funded and need to show some kind of path to profitability.

imbnwa 3y ago
People acting like Bun, which is also ventured funded, isn't going to be doing a lot of similar things once they stabilize their runtime. Node had a lot of runway in the era/climate it was made in.
- ramesh31 3y ago
  I also get the sense that Dahl ended up feeling slighted about his loss of control (see: ability to extract rent) of the Node ecosystem, and doesn't want to let that happen again. It feels almost quaint how open things were back then.
  - imbnwa 3y ago
    Interesting, didn't know that was a background intention

elbasti 3y ago

What makes jobs "tricky" is that jobs are--by definition--entirely side-effects. So: - What happens if the process where you called the job crashes? - What happens if the entire application crashes? - What happens if two threads/processes schedule the same job? - Should jobs be stored in memory? On disk? In a db? Are all sort of interesting questions. Presumably the Deno runtime deals with this in a way that's opaque to the user, but that using "a library" does not, especially in a language like Javascript where processes/jobs are not really first-class.