He was talking about iolists, and he's perfectly correct: an iolist is O(number of strings to concatenate), you need a single cons cell per element to concatenate regardless of their size.
> Garbage collection: rubbish. It can run on it's own thread
That adds an enormous amount of complexity to the GC in your generic unsafe language (java, go, C#, python, what have you), and requires hugely extensive work on it.
> Of course you need to be careful about the number of objects your "disposing"
You completely missed the point, which is that through the VMs design as a set of heaps (per process) with very little shared memory from Erlang's fairly simple m&s GC emerges a highly concurrent garbage collector. Not only that, but short-lived process can be tuned to never trigger a GC pass on their own heap. Java's concurrent GC strategies are still hit-or-miss and a dark art.
PS: and yes, if you put everything in the same erlang process, the GC completely breaks down to a pretty shitty M&S.
> * Refactoring... seriously? What happened to compilation errors?
I have no idea what you're trying to say here.
> Data Structures - I'm not sure what he's worked with before, but modern languages allow the transparency he mentions.
He listed them, was it really so hard to actually read the post?
Let me add: The key point of the GC per process is that when heaps are small, pause times are also small. And since GC is counted against a process reductions frequently GCing processes get swapped out all the time and will not hurt the latency of other processes.
He was talking about iolists, and he's perfectly correct: an iolist is O(number of strings to concatenate), you need a single cons cell per element to concatenate regardless of their size.
> Garbage collection: rubbish. It can run on it's own thread
That adds an enormous amount of complexity to the GC in your generic unsafe language (java, go, C#, python, what have you), and requires hugely extensive work on it.
> Of course you need to be careful about the number of objects your "disposing"
You completely missed the point, which is that through the VMs design as a set of heaps (per process) with very little shared memory from Erlang's fairly simple m&s GC emerges a highly concurrent garbage collector. Not only that, but short-lived process can be tuned to never trigger a GC pass on their own heap. Java's concurrent GC strategies are still hit-or-miss and a dark art.
PS: and yes, if you put everything in the same erlang process, the GC completely breaks down to a pretty shitty M&S.
> * Refactoring... seriously? What happened to compilation errors?
I have no idea what you're trying to say here.
> Data Structures - I'm not sure what he's worked with before, but modern languages allow the transparency he mentions.
He listed them, was it really so hard to actually read the post?