3 ms·
> But how many days must later be spent debugging issues like this? Will this time spent debugging be counted against your productivity gains you attribute to L
by freax 18y ago
> But how many days must later be spent debugging issues like this? Will this time spent debugging be counted against your productivity gains you attribute to Lisp? This is exactly the sort of problem Erlang has nailed down.
http://damienkatz.net/2007/12/erlang_vm_crash.html http://damienkatz.net/2007/12/erlang_vm_crash.html :
"So the Erlang VM died suddenly with a failed memory allocation. This is actually quite okay [...] However, the Erlang VM didn't restart automatically. Apparently we need to configure something for that to happen, only we can't figure out how to make it work. The documentation is either wrong, confusing or the feature is buggy. This is the kind of stuff we keep hitting in Erlang. It's fantastically productive for many tasks, but using some of the built-in libraries and features can be a huge time sink. (inets and xmerl immediately spring to mind)."
- damienkatz 18y agoYes, those things need to be pointed out. I don't want people to think that Erlang is a miracle productivly booster. It's not. The productivity gains are only there in certain application domains, and of course it also require good libraries to support it. But Erlang to me isn't as much about programmer productivity as it is about reliability. But when building highly reliable systems, of course it's a big productivity boost. I should point out we've abandoned xmerl (and xml altogether), and things have been much simpler since. We are in the process of moving off the inets http server to mochiweb. Hopefully that will also go smoothly.