5 ms·

This is a very overstated concern, in my opinion. Based on my experience, once you learn the common gotchas (lazy folds, WHNF, etc.) it's rarely an issue. Real-

by wyager 9y ago

This is a very overstated concern, in my opinion. Based on my experience, once you learn the common gotchas (lazy folds, WHNF, etc.) it's rarely an issue. Real-world programs (web servers, databases, etc.) typically end up using frameworks that deal with strictness concerns for you anyway. For maybe the first couple weeks I was learning Haskell, this was a source of confusion, but I don't seem to run into it anymore. If it's really a struggle for some reason, you can always take the nuclear option and enable strict mode on your code. Haskell is very good for writing extremely fast code that's also extremely composable, which most languages (even Rust, to a substantial degree) really struggle with. Haskell's pure non-strict semantics and support for fusion/rewrite systems means that you can write complex operations on vectors, byte arrays, text, etc. that span multiple modules but get compiled down to extremely tight in-place assembly code. Another way of looking at it is that the economies of scale for Haskell are very different. There's a higher up-front cost because you have to learn about how strictness works, but as a consequence you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C.

delhanty 9y ago
> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewart" [2]. The following is just my vague, uninformed impression, but Haskell and Go seem to be opposite ends of a spectrum, with Rust somewhere in between: Haskell: good for expert individuals and small teams. The language is highly sophisticated and the compiler is rather slow. At heart, it's a research language, so the direction might not always suit production use. If you contract out to a Haskell development shop, who do you turn to with your Haskell code-base if things don't work out? Go: designed by Google for their use-case - large teams of commodity programmers. It's very quick to onboard programmers - they can be productive and non-dangerous quickly. The language is very simple and the compiler is very quick - which is again good for scaling large teams. [1] https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ghc&lang2=gcc https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... [2] https://donsbot.wordpress.com/2008/05/06/write-haskell-as-fast-as-c-exploiting-strictness-laziness-and-recursion/ https://donsbot.wordpress.com/2008/05/06/write-haskell-as-fa...
- wyager 9y ago
  The benchmarks game falls squarely under the umbrella of "short, simple programs", not the sort of real-world stuff where you would benefit from having a language that scales well. That said, Haskell performs pretty well in the toy benchmarks anyway. Your comparison between Haskell and Go is about market size, not language design. I suspect you would have a similarly hard time finding Rust devs as Haskell devs (i.e. mildly less convenient than a popular language like Python or Go).
  - delhanty 9y ago
    > .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. I don't mean to be personal, but your quantative claim smells a little like unsubstantiated BS. Do you have any data to back it up? > That said, Haskell performs pretty well in the toy benchmarks anyway. Currently, "pretty well" looks like GHC performance is 50% to 10% of hand-crafted C using perhaps 5 times as much memory. (If the GHC program builds at all that is.) fannkuch-redux Haskell GHC: 16.70 sec 7,628 mem C gcc: 8.97 sec 1,660 mem spectral-norm Haskell GHC: 4.06 sec, 9,880 mem C gcc: 1.99 sec, 1,824 mem n-body Haskell GHC: 24.48 sec, 6,468 mem C gcc: 9.96 sec, 1,016 mem reverse-complement Haskell GHC: 1.39 sec, 132,176 mem C gcc: 0.42 sec, 143,948 mem mandelbrot Haskell GHC: 11.64 sec, 41,180 mem C gcc: 1.65 sec, 32,684 mem fasta Haskell GHC: 14.68 sec, 455,088 mem C gcc: 1.33 sec, 2,856 mem binary-trees Haskell GHC: 26.28 sec 511,444 mem C gcc: 2.38 sec 131,728 mem k-nucleotide Haskell GHC: Make Error C gcc 0.06 sec ? mem pidigits Haskell GHC: Make Error C gcc: 0.06 sec ? mem regex-redux Haskell GHC: Make Error C gcc: 0.02 sec ? mem Haskell GHC: The Glorious Glasgow Haskell Compilation System, version 8.0.2 C gcc: gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
    - Tarean 9y ago
      The make errors are a bit weird because the programs build on my machine no problem. In parts haskells slowness seems to be because no one cares enough to work on it. Can't say for sure, though, so maybe I just should try a task and implement it to see how fast it'd be without amazing optimization foo. Although of course these benchmarks aren't really representative of the real world because they'd just end up as a c ffi call in most languages if they actually were that performance critical.
marcosdumay 9y ago
Some real world programs have a very clear request-response cycle that Haskell deals with very well (although a more predictable garbage collector would be great). Other real world programs have a strict "always push things into the world, react to inputs" cycle that Haskell has trouble supporting.

by wyager 9y ago

delhanty 9y ago

> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewart" [2]. The following is just my vague, uninformed impression, but Haskell and Go seem to be opposite ends of a spectrum, with Rust somewhere in between: Haskell: good for expert individuals and small teams. The language is highly sophisticated and the compiler is rather slow. At heart, it's a research language, so the direction might not always suit production use. If you contract out to a Haskell development shop, who do you turn to with your Haskell code-base if things don't work out? Go: designed by Google for their use-case - large teams of commodity programmers. It's very quick to onboard programmers - they can be productive and non-dangerous quickly. The language is very simple and the compiler is very quick - which is again good for scaling large teams. [1] https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ghc&lang2=gcc https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... [2] https://donsbot.wordpress.com/2008/05/06/write-haskell-as-fast-as-c-exploiting-strictness-laziness-and-recursion/ https://donsbot.wordpress.com/2008/05/06/write-haskell-as-fa...

wyager 9y ago
The benchmarks game falls squarely under the umbrella of "short, simple programs", not the sort of real-world stuff where you would benefit from having a language that scales well. That said, Haskell performs pretty well in the toy benchmarks anyway. Your comparison between Haskell and Go is about market size, not language design. I suspect you would have a similarly hard time finding Rust devs as Haskell devs (i.e. mildly less convenient than a popular language like Python or Go).
- delhanty 9y ago
  > .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. I don't mean to be personal, but your quantative claim smells a little like unsubstantiated BS. Do you have any data to back it up? > That said, Haskell performs pretty well in the toy benchmarks anyway. Currently, "pretty well" looks like GHC performance is 50% to 10% of hand-crafted C using perhaps 5 times as much memory. (If the GHC program builds at all that is.) fannkuch-redux Haskell GHC: 16.70 sec 7,628 mem C gcc: 8.97 sec 1,660 mem spectral-norm Haskell GHC: 4.06 sec, 9,880 mem C gcc: 1.99 sec, 1,824 mem n-body Haskell GHC: 24.48 sec, 6,468 mem C gcc: 9.96 sec, 1,016 mem reverse-complement Haskell GHC: 1.39 sec, 132,176 mem C gcc: 0.42 sec, 143,948 mem mandelbrot Haskell GHC: 11.64 sec, 41,180 mem C gcc: 1.65 sec, 32,684 mem fasta Haskell GHC: 14.68 sec, 455,088 mem C gcc: 1.33 sec, 2,856 mem binary-trees Haskell GHC: 26.28 sec 511,444 mem C gcc: 2.38 sec 131,728 mem k-nucleotide Haskell GHC: Make Error C gcc 0.06 sec ? mem pidigits Haskell GHC: Make Error C gcc: 0.06 sec ? mem regex-redux Haskell GHC: Make Error C gcc: 0.02 sec ? mem Haskell GHC: The Glorious Glasgow Haskell Compilation System, version 8.0.2 C gcc: gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
  - Tarean 9y ago
    The make errors are a bit weird because the programs build on my machine no problem. In parts haskells slowness seems to be because no one cares enough to work on it. Can't say for sure, though, so maybe I just should try a task and implement it to see how fast it'd be without amazing optimization foo. Although of course these benchmarks aren't really representative of the real world because they'd just end up as a c ffi call in most languages if they actually were that performance critical.

marcosdumay 9y ago

Some real world programs have a very clear request-response cycle that Haskell deals with very well (although a more predictable garbage collector would be great). Other real world programs have a strict "always push things into the world, react to inputs" cycle that Haskell has trouble supporting.