quoting myself from reddit: About atoms: "calling integer_to_list and then list_to_atom on the current loop index." There is a function called 'list_to_existi

quoting myself from reddit: About atoms: "calling integer_to_list and then list_to_atom on the current loop index." There is a function called 'list_to_existing_atom' done to circumvent that. Note that each atom is only 4 bytes (8 bytes in a 64bit system) and you have to use several hundred of thousands of them for it to be problematic. As long as you don't dynamically create atoms from user input, it's not a problem. Point 2 about 'process leaks' is valid, but fixable by the programmer again. Just make sure processes can die, or create a pool (what servers like mochiweb and YAWS do, as far as I know). Flooding a mailbox has bitten lots of people in the ass, and is even a problem in the default settings of the OTP logger. Lots of people have gotten problems with the selective pattern match making their app die (too much in, not enough out). It's probably the biggest menace for an Erlang VM because it mainly becomes apparent under heavy load, which is sometimes harder to simulate and test for. As for the binary problem, a general behavior causing the problem is that when you split a large binary, the fragments are just references to the big one until the process dies. So using these can often mean you'll mess up the reference counting. A work-around for that is to call a variation of "list_to_binary(binary_to_list(Bin))" which will allocate the binary as a new one separate from the large one. Erlang definitely has problems, but to crash the VM with them takes some kind of mistake or lack of awareness on the programmer's side. I'm not writing this to contradict James Hague (he's one of the bloggers I like the most), just thought I'd complete/comment.