Actually I learned this myself just this week. Don't fear the binaries in Erlang. You need to learn how they work, and in particular they can surprise you a bit if you don't turn fullsweep on by hanging around in the binary heap longer than you'd expect after all processes are done with it, but you are not doing the runtime any favors by using a lot of "strings" instead. (Fullsweep isn't the only answer either, it's just an easy thing to quickly say in an HN post.)
In Erlang, slices of binaries are by default references to the original, and if you want a true copy (within a single Erlang OS process, sending it across processes will make one automatically of course) you need to ask for it, with binary:copy, available only in relatively recent releases. In the context of where Erlang tends to run, I think this is the correct default behavior, but it does mean that you end up having to do at least a little smidge of memory-management-type thinking. Since your Erlang code is very likely to be something that takes a packet in, does "something", and sends it somewhere else without hanging on to it indefinitely, this can work well as long as you don't leak references.
> Actually I learned this myself just this week. Don't fear the binaries in Erlang.
I don't understand why you would though: Erlang's binaries are one of the sexiest, simplest, most readable and most fluent ways to work with raw binary data.
Sure they're reference-counted on a shared binary heap instead of the pre-process one and you have to be careful about sharing sections of binaries and hanging onto them, but apart from that it's utterly fantastic.
In Erlang, slices of binaries are by default references to the original, and if you want a true copy (within a single Erlang OS process, sending it across processes will make one automatically of course) you need to ask for it, with binary:copy, available only in relatively recent releases. In the context of where Erlang tends to run, I think this is the correct default behavior, but it does mean that you end up having to do at least a little smidge of memory-management-type thinking. Since your Erlang code is very likely to be something that takes a packet in, does "something", and sends it somewhere else without hanging on to it indefinitely, this can work well as long as you don't leak references.