3 ms·

There seems to be an unhealthy obsession with beating C in some corner of the Haskell community. It makes even less sense nowadays when some of the most popular

by simias 7y ago

There seems to be an unhealthy obsession with beating C in some corner of the Haskell community. It makes even less sense nowadays when some of the most popular languages out there are Javascript and Python, clearly C-grade performance is not required anymore by the vast majority of applications. I actually wrote a comment (in 2013, but the page I'm referencing doesn't appear to have changed one bit) where I shared my experience looking at haskell.org's introduction that was filled with FUD regarding C and how Haskell was so much better and faster: https://news.ycombinator.com/item?id=5090808 https://news.ycombinator.com/item?id=5090808 Maybe if they had actually tried to teach me the language instead of that bad faith "used car salesman" tactic I'd be writing Haskell these days.

tom_mellior 7y ago
> There seems to be an unhealthy obsession with beating C in some corner of the Haskell community. I think it's about the same for pretty much any language in the "statically typed, compiled" camp. You'll see "faster than C" claims for Rust and Go as well, for example.
- simias 7y ago
  That's true. I guess what makes Haskell stand out to me is that at this point it's fairly clear that the assertion is mostly wrong (i.e. idiomatic Haskell is not faster than idiomatic C at most algorithmic tasks, and often significantly slower) and instead of doing the reasonable thing and saying "additional safety and expressiveness is more important than raw performance for most applications" (something I'd completely agree with personally) they double-down with these meaningless, unfair benchmarks. Meanwhile Rust is genuinely competitive with C performance-wise and thanks to generics and things like more aggressive inlining can actually equal or even beat C without requiring esoteric micro-optimizations. Of course the drawback is that writing Rust code is significantly more complicated and more restrictive.
- Annatar 7y ago
  And the really funny part for us C practitioners is, we know we'll rarely be as fast as machine code generated from Fortran.
Annatar 7y ago
C-like performance is required more than ever: we have to have monster multicore machines with gigabytes of memory just to run any software. That's absolutely ridiculous.
Ahri 7y ago
I've immersed myself in the Haskell community for the past couple of years and while I'd agree that a few posts try to race a Haskell implementation against a C version, these are in the extreme minority. I feel that you have mis-characterised a whole community, very few of whom care to make Haskell faster than C and overwhelmingly share your view that "C-grade performance is not required". Further, in the posts I've read of people comparing to C, if anything C is held up as the benchmark as a mark of respect - not as something to cheat against, not to try to say that Haskell is better. Indeed Haskell's FFI out to C is really nice, and demonstrates the pragmatic side of this ivory-tower language :) This post first embraces its clickbait article and then highlights that even though the Haskell version may be faster on multicore systems (at least for ascii - the unicode version may be incorrect wrt. unicode spaces), but that in practical situations without caching this may not provide any benefit. You're acting as if OP submitted his binary to Apple, *BSD and all the Linux distros with a pull request saying his is better! It's a fun post golfing some Haskell performance issues.

by simias 7y ago

tom_mellior 7y ago

> There seems to be an unhealthy obsession with beating C in some corner of the Haskell community. I think it's about the same for pretty much any language in the "statically typed, compiled" camp. You'll see "faster than C" claims for Rust and Go as well, for example.

simias 7y ago
That's true. I guess what makes Haskell stand out to me is that at this point it's fairly clear that the assertion is mostly wrong (i.e. idiomatic Haskell is not faster than idiomatic C at most algorithmic tasks, and often significantly slower) and instead of doing the reasonable thing and saying "additional safety and expressiveness is more important than raw performance for most applications" (something I'd completely agree with personally) they double-down with these meaningless, unfair benchmarks. Meanwhile Rust is genuinely competitive with C performance-wise and thanks to generics and things like more aggressive inlining can actually equal or even beat C without requiring esoteric micro-optimizations. Of course the drawback is that writing Rust code is significantly more complicated and more restrictive.
Annatar 7y ago
And the really funny part for us C practitioners is, we know we'll rarely be as fast as machine code generated from Fortran.

Annatar 7y ago

C-like performance is required more than ever: we have to have monster multicore machines with gigabytes of memory just to run any software. That's absolutely ridiculous.

Ahri 7y ago

I've immersed myself in the Haskell community for the past couple of years and while I'd agree that a few posts try to race a Haskell implementation against a C version, these are in the extreme minority. I feel that you have mis-characterised a whole community, very few of whom care to make Haskell faster than C and overwhelmingly share your view that "C-grade performance is not required". Further, in the posts I've read of people comparing to C, if anything C is held up as the benchmark as a mark of respect - not as something to cheat against, not to try to say that Haskell is better. Indeed Haskell's FFI out to C is really nice, and demonstrates the pragmatic side of this ivory-tower language :) This post first embraces its clickbait article and then highlights that even though the Haskell version may be faster on multicore systems (at least for ascii - the unicode version may be incorrect wrt. unicode spaces), but that in practical situations without caching this may not provide any benefit. You're acting as if OP submitted his binary to Apple, *BSD and all the Linux distros with a pull request saying his is better! It's a fun post golfing some Haskell performance issues.