Hacker News Reader

Comment by kevingadd | Hacker News Reader

The author mentions how he thinks representing all strings as linked lists is the 'right thing to do', and later complains about the language's runtime performance. These two things should immediately seem connected to anyone who has ever heard the term 'L1 Cache', and it makes me wonder if the author has heard of it. There are in fact many runtime environments with support for representing strings as linked lists (I believe V8 and SpiderMonkey both do this) but it is never a universally correct choice. If you compose a long string out of a linked list of single character strings your performance will be miserable.

Then again, when I reached the part where he says "I actually like the fact that there are not many Erlang libraries available" I started wondering whether this entire article is a giant troll...

View on HN

> The author mentions how he thinks representing all strings as linked lists is the 'right thing to do'

No. He wasn't talking about strings-as-linked-list there: list concatenation is O(N) of the first list, not O(1).

OP was talking about Erlang's iolists which are arbitrarily nested lists of binaries (~bytestrings) and strings (list of integers) which the IO port will iterate and serialize when it needs to: http://prog21.dadgum.com/70.html. Concatenating two lists (or two binaries, or a list and a binary) by creating an iolist merely requires allocating 2 cons cells, regardless of the size of the items being concatenated.

And because you misunderstood this, your whole comment falls down.

> and later complains about the language's runtime performance. These two things should immediately seem connected

They aren't and have nothing to do with one another. His complaint is about the erlang interpreter/VM being fairly slow. Because it is. Not strings being slow, the interpreter itself.

Point of information for this thread: Erlang's iolist are similar (in data structure and complexity) to Haskell's bizarrely named Difference List, which is explained a bit more here:

http://hackage.haskell.org/packages/archive/dlist/0.4.1/doc/...

It's basically a tree, which is efficient (amortized O(1) per element) for many list appends followed by one iteration.

> "I actually like the fact that there are not many Erlang libraries available" I started wondering whether this entire article is a giant troll...

It's an opinion piece. It is a disadvantage that helped him learn the language better. But he also let you know about it. So if you are into writing your own libraries for some things, it is not the language for you.

In the same vein I could say the different than C syntax is an advantage as well. It tells my brain to shift gears and stop writing C/Java/C#/C++ code and start thinking in terms of processes and patterns. Is that a trolling comment? If you feel so go ahead and click the down arrow.

> The author mentions how he thinks representing all strings as linked lists is the 'right thing to do

I think the author just likes that the runtime for string concatenation is fast; not sure why he ignores the fact that you'd need to chase pointers for every other string op.

He then goes on to talk about openCL and how he can use his erlang code to use the benefits of the openCL compiler, but of the 25 years of using this language, he's only had this benefit for a couple of years.

Sounds wacky to me.

Remember that Erlang is a functional language with a persistent heap. You often create your concatenation only once and if you need to process strings, you process your strings in another, symbolic, representation.

Thus the raw string-processing speed isn't important in usual programs. The iolist() primitive is there to make it fast to just gather up data that has to go over a socket and essentially writev() it to the socket (guess what happens internally in the VM...)

So it is usually not the case you pay the pointer chasing in typical Erlang programs.

Then again, when I reached the part where he says "I actually like the fact that there are not many Erlang libraries available" I started wondering whether this entire article is a giant troll...

Why? I wouldn't think like that, but I do think he explains it well

There is a great explanation of IO lists in Learn You Some Erlang [1], but in short — an IO list is functionally equivalent to a string builder, allowing you to accumulate individual strings in O(1) time.

[1]: http://learnyousomeerlang.com/buckets-of-sockets

Reply on news.ycombinator.com