Hacker News new | past | comments | ask | show | jobs | submit login

Haskell's garbage collector is compacting (see below). When the GC compacts, it is very easy to put linked list entries together for more efficient access.


"it is very easy" but have you ever actually measured whether it does, and whether the resulting performance is high?

Haskell has list fusion so efficient list code never actually constructs a list that lives on the heap to be GC'd to start with.

So, with that proviso, the answer to your question is yes and that as a result sometimes list code can be faster than vectors.

[citation needed, in the form of actual benchmarks]

The thing is that list fusion and whatnot is all just there to get around the handicap that was placed there in the first place by the language paradigm. So you start by insisting on shooting yourself in the foot, then put lots of armor on your boot so the bullet hopefully bounces off.

I assume by "vectors" you mean arrays ... there is no case in which this can be faster than arrays, because in the limit, if the list fusion system works perfectly, it is just making an array. A thing can't be faster than itself.

If you need something predictable, you'll usually use a vector in Haskell. Nothing obligates you to use a list.

I regard it as more of a pleasant surprise and something that surprises/confuses people when they benchmark `String` (which is `[Char]` under the hood) against `Text` (which is an `Array` under the hood: http://hackage.haskell.org/package/text- )

I've had `String` come out faster than `Text` in benchmarks plenty of times, including for a colleague when we were writing up this post https://lorepub.com/post/2016-12-17-Haskell-Pitfalls

What I'm not going to do is perform free labor for a man with a bad attitude who is 100x wealthier than I am. I'm not saying you should design a performance oriented language around short-cut fusion, but the "cost" of using Haskell is generally not what people think it is.

The span of applicability for Haskell, IME, ranges from Java/Golang to Ruby. It's no replacement for C++, but it does come close in some applications that aren't hard/soft real-time.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact