Hacker News new | ask | show | jobs
by demosthanos 927 days ago
Is this really that surprising of a behavior, though? PHP apps threw away state after each request, and in the Node.js world data doesn't persist across server restarts or across instances of the app.

The only way I could see someone being confused about this is if they thought Deno Deploy was just a single VM running a single instance their code.
2 comments
fendy3002 926 days ago
It is surprising behavior, because if the code can be accessed inside the scope, it is safe to assume that any modification to it will change the state, since it is still inside closure. If they throw `s++` with accessing undefined variable error, it will be much better. It'll be better if they can catch it during compile / validating / linting level.

And yes, PHP's behavior is surprising too. Unless we're doing scratch PHP without any classes or frameworks, any temporary variables become non-intuitive.

link
pseudosavant 927 days ago
Kind the point of Deno Deploy is that you never have to think about a unit like a VM or container.

The runtime shouldn’t allow you to mutate variables in a parent scope. It probably shouldn’t allow any shared context at all. Because it isn’t actually doing that.

Everything should be passed into the cron function as an argument. It seems like this should be more like the interaction with web workers where those clearly execute in their own context.

link
demosthanos 926 days ago
> The runtime shouldn’t allow you to mutate variables in a parent scope. It probably shouldn’t allow any shared context at all. Because it isn’t actually doing that.

What you're proposing alters the semantics of JavaScript-the-language, which is outside the scope of the Deno project. Pretty much everyone is already in the habit of avoiding variables in the global scope. Why should they go to the trouble of redefining the semantics of JavaScript for something that is already widely understood?

link
pseudosavant 926 days ago
`Deno.cron` isn't JavaScript-the-language. It is part of a runtime. They could implement this in a different way. Just like how Web Workers still just use JavaScrip-the-language, but within a different execution context than `<script>`.
link