Comment by paupino_masano | Hacker News Reader

Comment by paupino_masano | Hacker News Reader

Warning: I'm not usually overly critical on articles: but this one I can only think is a little bit of flame bait - a little bit of truth from various languages turned into fact?

* String concatenation: blatant misinformation. The only reason the default implementation of Strings is slow is because they're made immutable for a reason. This if for speed and predicability - if you're wanting to build a String then funnily enough: use a String Builder.

* Garbage collection: rubbish. It can run on it's own thread (which can ultimately run on it's own processor). In languages such as Java and .NET the garbage collector has been written so that it collects only what is disposed. Of course you need to be careful about the number of objects your "disposing" (too many can cause the processor to be collecting more than running) but the same is with any language: Erlang included.

* Refactoring... seriously? What happened to compilation errors? Isn't it worse if the structure sends less at runtime?

* Data Structures - I'm not sure what he's worked with before, but modern languages allow the transparency he mentions. He mentions "easy to manipulate undocumented data structures" - of course he is asking for trouble there. There are ways around this in OO languages, and worst come worst: roll your own. Don't mess with the internals where you need to "worry about the original author renaming variables ".

I seriously doubt the authors experience in the languages he mentions. Even so, I doubt his understanding...

> * String concatenation: blatant misinformation.

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.

Actually, the Clojure world has a good critique against using objects when datastructures are generally better. Rich Hickey has all sorts of talks where he explains why datastructures beat objects. One reason is that datastructures let you write more generic code, and you have all sorts of powers which the original author didn't need to plan in advance. For example, you can use any operators which operate on mapping types. And anything built on top of those operators, like set operations over tuples.

(Disclaimer: I've written only one service in Erlang, without OTP, so I can't evaluate all the claims.)

Reply on news.ycombinator.com