3 ms·

Here is my guess: because it's Arc with closures and web closures have a timeout. It can be long or short, but hardly infinite.

by mojuba 18y ago

axod 18y ago
If that's the case, closures don't seem like a good idea in this sort of context.
- mojuba 18y ago
  But you are not going to write a comment infinitely, are you? Wouldn't 12 hours be OK, for example? It's about memory allocated for the hash table. If they add some RAM and change the timeout to 12 hours you won't even notice what's going on under the hood. And closures are nice from programming perspective. Should I say it's almost definitely the future of server-side development... ;)
  - ken 18y ago
    This isn't about closures. This is about using continuations on the server to store client state. Surely they could come up with some way to store trivial state in the URL's GET params, without making life too miserable for the programmers. Nearly 10 years ago, Nielsen wrote about "URL as UI" <http://www.useit.com/alertbox/990321.html> http://www.useit.com/alertbox/990321.html>. URLs that break after an indeterminate time are not good UI.
    - natrius 18y ago
      If you look at the URLs for voting on comments, they aren't using continuations. I don't see any reason why comments should.
      - mooneater 18y ago
        The reply link I used to add this comment, had timed out, which seems wrong. Have continuations just moved the the complexity -- making some aspects more elegant, while resulting in undesired side effects like expiring reply links? I find that often happens when I'm designing abstractions - complexity moves somewhere else, and I later get unexpectedly bitten.
    - mojuba 18y ago
      You are right, I meant continuations, sorry. HN is using URLs for passing those hash keys (if they are hash keys of course), but they need to store them on the server as well. So URLs themselves don't solve the problem in this case. It's actually that HN doesn't use databases, where they could keep session-specific data much longer.

Here is my guess: because it's Arc with closures and web closures have a timeout. It can be long or short, but hardly infinite.

by mojuba 18y ago

Here is my guess: because it's Arc with closures and web closures have a timeout. It can be long or short, but hardly infinite.

axod 18y ago

If that's the case, closures don't seem like a good idea in this sort of context.

mojuba 18y ago
But you are not going to write a comment infinitely, are you? Wouldn't 12 hours be OK, for example? It's about memory allocated for the hash table. If they add some RAM and change the timeout to 12 hours you won't even notice what's going on under the hood. And closures are nice from programming perspective. Should I say it's almost definitely the future of server-side development... ;)
- ken 18y ago
  This isn't about closures. This is about using continuations on the server to store client state. Surely they could come up with some way to store trivial state in the URL's GET params, without making life too miserable for the programmers. Nearly 10 years ago, Nielsen wrote about "URL as UI" <http://www.useit.com/alertbox/990321.html> http://www.useit.com/alertbox/990321.html>. URLs that break after an indeterminate time are not good UI.
  - natrius 18y ago
    If you look at the URLs for voting on comments, they aren't using continuations. I don't see any reason why comments should.
    - mooneater 18y ago
      The reply link I used to add this comment, had timed out, which seems wrong. Have continuations just moved the the complexity -- making some aspects more elegant, while resulting in undesired side effects like expiring reply links? I find that often happens when I'm designing abstractions - complexity moves somewhere else, and I later get unexpectedly bitten.
  - mojuba 18y ago
    You are right, I meant continuations, sorry. HN is using URLs for passing those hash keys (if they are hash keys of course), but they need to store them on the server as well. So URLs themselves don't solve the problem in this case. It's actually that HN doesn't use databases, where they could keep session-specific data much longer.