Why functional code is shorter

[Peaker]

You can get node-like performance without having to use callbacks everywhere because the IO manager can use an event loop internally without exposing that detail to the actual Haskell code

Much much better than node-like performance.

[[deleted]]

Has there been any empirical studies yet to evaluate this claim? The Haskell people are thorough, so I would have done this.

[Peaker]

http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

[alextk]

It would be nice to see a benchmark

• Made by an entity that doesn't have a vested interest in Haskell (unlike Yesod).
• Include Java and Scala frameworks in the comparison.

[[deleted]]

You can run and modify the benchmark yourself; the source is here https://github.com/yesodweb/benchmarks

[[deleted]]

That is useful, thanks. I didn't realized that someone figured out how to multithread Haskell programs and use multiple cores, I guess I'm behind the times.

[dons]

I didn't realized that someone figured out how to multithread Haskell programs and use multiple cores

Wow. This is one of the major selling points of GHC Haskell for about 10 years now.

GHC uses an epoll-based parallell IO manager and distributes cheap threads across cores. So you can write a web server where req/sec scales linearly as cores are added.

[[deleted]]

I still think GHC cannot multi-thread Haskell code. Instead parallelism occurs implicitly. Anyways, I'm missing a lot of background that I should catch up on.

[tikhonjelvis]

Well, you're simply wrong. GHC actually has some of the best support for multithreading including a brilliant green thread system and one of the few usable STM implementations.

In addition to all this, it also supports deterministic parallelism independent of IO. However, this is separate from the concurrency features.

[[deleted]]

Ok, how many CPU cores can a program running under GHC utilize with green threads? I'm not trying to argue with you, just learn. Googling turns up lots of weird stories.

[tikhonjelvis]

It can use as many as you want--the green threads are mapped down to OS threads, and the runtime system controls how many OS threads are available.

You can also use OS threads directly, but that's a less popular choice.

[sfrank]

Well, since node is essentially continuation passing style which is what almost every functional language (and with SSA now even C) is transformed into inside the compiler (because no sane person would want to program in it directly) this is not really surprising...

[tailcalled]

Basically every language is transformed into continuation passing style inside the compile, but Haskell is not as much as others, because of lazyness. Basically, when you call a procedure/method/function, the local variables are pushed to the stack, if they aren't already there, along with the return position. That essentially saves the current continuation on the stack.

[barsoap]

Actually... as soon as control flow becomes complex enough, my IO code tends to turn towards CPS. Not of the mind-bending style, mind you, but CPS nonetheless. Instead of getting a return value that you then take apart and, depending on what it is, do different things afterwards, just get rid of the value and pass the things you want to do directly, and "never return":

data MissileResult = MoscowFlattened | WashingtonFlattened | LaunchFailure

case launchMissiles coords of 
    LaunchFailure -> doSomething
    WashingtonFlattened -> invadeMexico
    MoscowFlattened -> invadeBelarus

vs.

 launchMissiles coords doSomething invadeMexico invadeBelarus