[coolplants]

Big issue with Haskell adoption is the number of hoops you have to jump through to write efficient code in it. Haskell abstracts away the idea of a procedural VM implementing the code underneath, but you often need that exposed to finagle your code into a form that’s efficient.

Haskell programming ethos is opposed to that, the language wants people to focus on the semantics of computation not the method. Yet we must be able to specify computation method if we want our programs to operate efficiently.

The truth is that the Haskell compiler will never be able to automatically translate idiomatic Haskell code into something that’s competitive with C in the common case. once you start finagling your haskell code to compete with C you’ve negated the point of using Haskell to begin with.

[the_af]

> The truth is that the Haskell compiler will never be able to automatically translate idiomatic Haskell code into something that’s competitive with C in the common case.

Is this something you have experience with, or are you just theorizing? I know there are pitfalls to Haskell development, but to assert that "the common case" has uncompetitive performance seems wrong to me.

My problem with this kind of assertions is that often -- not saying it's your case, that's why I'm asking -- they come from people who imagine how it must be (or read it in a blog), often coming from a place of never really having tried to solve something with the language, and this sadly percolates into popular wisdom ("Haskell is not good for this or that"). Something similar happened to Java's allegedly "poor" performance, way past the point Java software sometimes outperformed C in many areas.

[jerf]

I think it's a common problem with almost all, if not all, languages that come to us out of the 1990s that they are fundamentally built on the presumption that "someday" compilers may save us. Well, "someday" is pretty much here, and they've all failed, as far as I'm concerned. (If you're happy with 10x-slower-than-C and substantial memory eaten to get even that fast, YMMV, but it's not what was hoped for. No sarcasm on that, BTW; sometimes that's suitable, just like sometimes 50x-slower-than-C is suitable. But it's not what was hoped for.)

Haskell can do some pretty tricks with specific code if you tickle it right, but if you just write general, normal code, it's faster than Python (a low bar, Python qua Python is nearly the slowest language in anything like common use) but not a generally "fast" language. "Someday" is here; if it's not "generally C-fast" today, I see no particular reason to believe it will be in the future either, especially since GHC seems to have spent a great deal of its design budget.

It would be interesting to see someone's take on Haskell, but where they write the language from the very beginning to be a high-performance language. There's probably multiple points in this design space that would be possible. Arguably Rust is nearly one of them, and getting even closer in the next few years.

[tjalfi]

You might be interested in Cliff Click’s aa[0].

It’s still under development but intended to be a high performance functional language.

The author has substantial experience in JITs and compilers.

[0] https://github.com/cliffclick/aa

[coolplants]

Yes I have many many hours of experience with Haskell and familiarity with functional programming. I’m speaking from experience.

Optimizing Haskell code is a huge downer. The experience of having to throw away beautiful code and rewrite it in C++ or non-idiomatic Haskell purely for performance reasons is extremely disheartening. I don’t recommend it.

[mrkeen]

> The truth is that the Haskell compiler will never be able to automatically translate idiomatic Haskell code into something that’s competitive with C

I don't dispute this. My problem is that people will use this as a reason dismiss Haskell, and then use Python.

[whateveracct]

Haskell actually does a great job when you do need to drop to C (or lower-level Haskell) for performance. It has a great FFI, a bunch of modules around low-level programming (raw ptrs w/arithmetic even), and things like the ST trick and (soon) LinearTypes to help you build interfaces that guarantee your impurity doesn't leak when called by pure code.

Haskell code tends to be pretty fast as-is, and tbh I don't see the problem with having to think about performance when you're writing performance sensitive code. When you do need to hand-optimize, Haskell does not get in your way or make it impossible.

Also, many extremely complex Haskell abstractions can be optimized away completely by GHC! Generics, lenses, and the state monad come to mind.

[coolplants]

IMO I’d rather just write idiomatic C++ then non-idiomatic ghc-specific Haskell code if performance is important, and it nearly always is.

[whateveracct]

The thing is, like 20% of your program ends up being non-idiomatic, ghc-specific Haskell. I suppose for certain applications it could end up being the whole thing, but in general I'm thinking optimized Haskell is in that ballpark tops.

And idiomatic Haskell's performance is plenty acceptable for a variety of common use-cases (so not "nearly always is")

[coolplants]

In my experience that has not been the case. Either unacceptably slow computation or High memory usage.

[whateveracct]

I mean, what use-case was this?

I've deployed plenty of web services & data processing jobs in Haskell and the RTS has never been a bottleneck or issue. So I'm guessing you weren't doing an IO-bound activity (where Haskell is quite good.)

[hopia]

You're right in that you don't spend time on Haskell thinking about how the code actually executes.

But I honestly don't think performance is the reason majority of the developers shy away from Haskell. Most often you achieve relatively good performance without giving it any thought. At least compared to its peers, I mean other high level languages you'd use to solve the same problem.

[coolplants]

It’s not a problem until it is, then it’s a pretty obnoxious problem.