4 ms·

The article is about that it is FORCING you to do it. Erlang is designed to restart processes, because they also know it's very hard to keep state but don't lea

The article is about that it is FORCING you to do it. Erlang is designed to restart processes, because they also know it's very hard to keep state but don't leak memory or be in a good state for a long time. Every application server has an option to "restart after N number of requests" for the exact same reason.

toast0 8y ago
Erlang is designed to restart processes when stuff goes wrong, because repairing is hard, and restarting is easy. This is different than PHP -- I hope my Erlang processes will have years of uptime, but I'm ok if they don't. My PHP requests have 30 seconds to live, and if they make it that long, they'll be systematically murdered (and, in some environments, the process they live in will be murdered after N requests, because even though PHP makes it hard to leak memory, developers rise to the challenge). This property is definitely one of the things I love about PHP -- when the request is done, everything is thrown away. This encourages you to do the minimum amount of work to get your HTML (or whatever) out the door. I'd like to say it forces you, but it doesn't really -- I've seen plenty of 'lightweight frameworks' that mess around for 50 ms creating cathedrals of objects that just get thrown away on a hello world page; if you do the minimum amount of work, you can get pages out the door pretty quick. Layering and abstraction can solve a lot of things, but it can't solve wrong abstractions.
attrezzarturo 8y ago
Sure, but I'd expect a paid web developer to be aware of the statelessness of http to begin with, and also to rely on testing to get any form of guarantee of any kind. What I find ironic is that creating the illusion of state in php is an absolute pain without a framework, which again applies to most language/server combos I've tried.

4 ms·

The article is about that it is FORCING you to do it. Erlang is designed to restart processes, because they also know it's very hard to keep state but don't lea

by Walkman 8y ago

toast0 8y ago
Erlang is designed to restart processes when stuff goes wrong, because repairing is hard, and restarting is easy. This is different than PHP -- I hope my Erlang processes will have years of uptime, but I'm ok if they don't. My PHP requests have 30 seconds to live, and if they make it that long, they'll be systematically murdered (and, in some environments, the process they live in will be murdered after N requests, because even though PHP makes it hard to leak memory, developers rise to the challenge). This property is definitely one of the things I love about PHP -- when the request is done, everything is thrown away. This encourages you to do the minimum amount of work to get your HTML (or whatever) out the door. I'd like to say it forces you, but it doesn't really -- I've seen plenty of 'lightweight frameworks' that mess around for 50 ms creating cathedrals of objects that just get thrown away on a hello world page; if you do the minimum amount of work, you can get pages out the door pretty quick. Layering and abstraction can solve a lot of things, but it can't solve wrong abstractions.
attrezzarturo 8y ago
Sure, but I'd expect a paid web developer to be aware of the statelessness of http to begin with, and also to rely on testing to get any form of guarantee of any kind. What I find ironic is that creating the illusion of state in php is an absolute pain without a framework, which again applies to most language/server combos I've tried.