+1

One approach that occurred to me was to use Haskell and Hackage for prototyping a design and then a Rust implementation for production.

It also reminds me of this from several years ago: GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, but still pure with effects only via monads. [1], [2].

Following on and presumably related to that PureScript is strict. [3]

[1] https://news.ycombinator.com/item?id=1924094

[2] http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.pp... (PowerPoint) Slide 40

[3] https://github.com/purescript/purescript/wiki/Differences-fr...

SPJ made a great lecture about this. It is very easy to follow and a fun insight into the academic history of modern functional languages https://www.youtube.com/watch?v=re96UgMk6GQ

Idris is strict too, but optional laziness is built into the compiler with the use of a special-cased Lazy wrapper of the form

  data Lazy a = Delay a

  force : Lazy a -> a
  force a = a

(purescript-lazy is also a thing, but I think it's not as seamless because of the "no compiler magic" position.)

In any case, what about -XStrict? I've never used it (or -XStrictData either), but isn't it a solution to the laziness problem, albeit a nuke-ish one at that?

And while we're thinking ahead, let's talk about the project to get linear types (something similar to Rust lifetimes, but weaker) into GHC :)

https://ghc.haskell.org/trac/ghc/wiki/LinearTypes

Why weaker? My understanding is that linear types provide a stronger guarantee than Rust's affine types: linear types guarantee that a value is used once, while affine types only guarantee that a value is used no more than once.

I think all he meant that strictness was an interesting paradigm that would differentiate a language enough to justify its existence alongside Haskell.

>Following on and presumably related to that PureScript is strict

Partly also to distinguish from GHCJS. Laziness in a strict language is really hard and PureScript generates semi-readable JavaScript.

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.

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?la...

[2] https://donsbot.wordpress.com/2008/05/06/write-haskell-as-fa...

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).

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

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.

But then remember that @wyager is claiming

>80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C

If it's really only 10% of the effort then one shouldn't really have "to work on it" to get semi-decent performance.

A more modest claim of say:

50% as fast as hand-optimized C for only 20% of the effort of hand-optimized C

would have been more credible and still a big win for many use cases.

   let outputs = map (exec content) tasks `using` parList rseq

[1]: http://benchmarksgame.alioth.debian.org/u64q/knucleotide.htm...

It cannot.

The line "main = putStr.pidgits.read.head =<< getArgs" has been commented out because the program author has optimised-away some of the work that must be done.

My fault (except for pi-digits and regex-redux).

I neglected to work-through the force-reinstalls that inevitably follow my update of the GHC compiler.

Done.

I referenced Rust because that was the article was about.

Swift and F# are languages that are not as basic as Go, but easier to find devs than Haskell.

That said, Rust has a lot going for it, even if there are a lot less devs than Swift.

That's a really bad benchmark. The power of Haskell is not that it's fast for generating the Mandelbrot set, it's that it allows you to things you couldn't do in any other language while still being fast enough to write e.g. compilers (Idris) or web services (Yesod).

Heh

Other real world programs have a strict "always push things into the world, react to inputs" cycle that Haskell has trouble supporting.

Well, yeah, Rust has manual memory management. Of course you don't get space leaks.

Anyways, Rust's laziness is not on par with Haskell. Iterators are great but it's not at all the same as e.g. GHC's lazy IO.

I wouldn't call Rust's memory management "manual". It's the only language I know of that I'd describe as having automatic memory management without garbage collection.

> Anyways, Rust's laziness is not on par with Haskell. Iterators are great but it's not at all the same as e.g. GHC's lazy IO.

Iterators, futures, and macros (for creating new language constructs) tend to provide the laziness I want. Beyond that, I've tended to find laziness as much a source of bugs as features. (Speaking from a perspective of having written and maintained large programs in Haskell, and in Rust.)

Trying to compete with Rust or C++ performance in Haskell is certainly frustrating to reason about :)

TL;DR: "fast" isn't well-defined, and for a lot (or even most) applications "fast" is about latency, not throughput, and Erlang is "faster" in that sense.

[1] https://making.pusher.com/latency-working-set-ghc-gc-pick-tw...

[2] they eventually abandoned Haskell for Go https://making.pusher.com/golangs-real-time-gc-in-theory-and...

The other big part of this is that it can make stream fusion predictable. Currently haskell programs can become 100x slower or faster after some innocuous change, so linear types will make it a lot easier to write fast haskell in general.

http://blog.tweag.io/posts/2017-03-13-linear-types.html

Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know.

GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-nonstrict data structures) so that the profiling tools become a last resort.

Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs that can make a single line worse than O(1).)

"Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.

Unless you use GCC's cleanup extension (which runs an arbitrary function when leaving a scope, similar to Rust's Drop trait). Or evil macros which turn innocent-looking code into something else (a well-known project, in some compilation modes, redefines the "if" keyword to track how many times each branch is taken). Or both at the same time (like hiding GCC's cleanup extension with a macro).

This is an oversimplification. Writing fast code for modern processors is all about how much time you spend waiting for memory.

e.g. bubblesort will beat quicksort for tiny lists or large lists which are already sorted.

Or, put another way, 1000 operations against 1ns latency memory (L1) has the same performance as 10 operations against 100ns latency memory (RAM).

  for (int i = 0; i < N; i++) {
    a[i] = 2*b[i];
  }
  for (int i = 0; i < N; i++) {
    c[i] = 2*d[i];
  }

  for (int i = 0; i < N; i+=2) {
    a[i] = 2*b[i];
    a[i+1] = 2*b[i+1];
    c[i] = 2*d[i];
    c[i+1] = 2*d[i+1];
  }

  foo :: [Int] -> [Int]

  foo :: [(Int, Int)] -> [(Int, Int)]

There are limits to how much you can restructure a list that's exported outside the compilation unit (my Haskell knowledge is fuzzy here so that's probably not the right terminology). And if the list is being re-stitched in odd ways it might be a bad idea. But as far as I can tell it ought to be doable and useful in most common cases. Of course maybe it's already doing this in those cases where it can prove that it works and that's why Haskell performance generally is good but fragile.

    for (int i = 0; i < N; i++)
        a[i] = 2 * b[i];
    for (int i = 0; i < N; i++)
        c[i] = 2 * a[i] + b[i];
    t = 0;
    for (int i = 0; i < N; i++)
        if (b[i] % 2 == 0) t += c[i];

    t = 0;
    for (int i = 0; i < N; i++)
        if (b[i] % 2 == 0) t += 5 * b[i];

In regards to assembling the stream: when the list is actually materialized, I assume it's done one element at a time, but the LLVM backend that GHC uses might be doing some loop unrolling, but I'm not sure.

Stream fusion doesn't require that all of the streams be the same type, though! Elements at different points in the stream can have wildly different sizes. For example, this would be fused:

    sum . map length . map double $ ["hello", "Symmetry"]
        where double x = concat [x x]

  foldr z f (build g) = g f z

  build :: (forall b. (a -> b -> b) -> b -> b) -> [a]
  build f = f (:) []

Haskell also has inline-C FFI support for "type safe" performance escape hatches (in the sense that you can manually bring C constructs into Haskell's type system): https://github.com/fpco/inline-c

The only way that Haskell inescapably suffers from performance hits (that I'm aware of) is not in its laziness or lack of imperative programming support, but in its periodic GC pauses. In such cases where GC pauses are an issue, I still think you can -- in principle -- write more and more performance critical pieces of your application in a non-GC language (in fact, you could do this in Rust just as well as C/C++). You can also manually trigger a GC pass, although you cannot -- to my knowledge -- manually stop and start GC passes in your code.

This is the approach I'm currently taking in a performance critical VR application where GC pauses could absolutely be an issue (using as much Haskell as possible, with C and GC triggers as an escape hatch). And if someone could point out a flaw in my reasoning (in particular, how GC pauses might be inevitably avoided even with C FFI), I would gladly pay them money, because it's so important I not get this one wrong :).

Read about that technique from Simon Marlow of Facebook's Haskell team. Of course it would be awesome to not have to worry about that.

Strictness annotations (and associated pragmas) only change the strictness of constructors and functions defined in my modules. I still have to reason about laziness as I use almost anything from the Haskell ecosystem.

Not saying these are insurmountable, unforgivable problems, just really annoying.

I honestly don't know how F# compares to Haskell over performance

Pity something's busted in the benchmarks game: http://benchmarksgame.alioth.debian.org/u64q/fsharp.html

Is F# working with .NET Core 2.0 Preview 1 for you?

Maybe the only thing I would complain would be the separation between integer and floating point math.

Something about people writing fast code with Flow/TypeScript than with plain JavaScript because the typing leads to less polymorphic code which is easier to optimize for the compiler.

This has nothing to do with performance per se. It doesn't make OCaml code faster than languages that allow you to write "+" for both int+int and float+float. The compiler knows anyway.

Anyway, Reason seems to have a bit nicer syntax than OCaml, I think.

Ran across Option in it the other day, though it's not used heavily. I really wish there was something like Haskell but with a runtime like Nim or Go. Perhaps that is OCaml?

I wish I could invest some time in working with Nim. It doesn't get as much attention as it deserves in my opinion, and it would really benefit from growing the community a bit.

Or this one https://developer.ibm.com/swift/

Basically 4.0 will introduce the notion of exclusive access, with more affine type ideas to follow up on 4.x.

EDIT: This feature is described by SE-0176.

https://github.com/apple/swift-evolution/blob/master/proposa...

"It only does what is needed!"

I didn't use Haskell but Nix and at least there it seemed reasonable to "not do" everything.

I enjoy writing Haskell for small hobby projects, but I doubt I would choose it for real work now that F# and Rust exist.

In Haskell when the compiler misses an optimization the performance hit is potentially unbounded, as it could think anything is a dependency. (You want the first N digits of pi? Just wait while I calculate all of them for you...)

I don't think that example cold actually happen, or at least I can't see how it would happen in Haskell.

* The ability to define control flow (structures) as abstractions instead of primitives.

* The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms.

* Performance increases by avoiding needless calculations, and error conditions in evaluating compound expressions."

In my several-year experience as a professional Haskell developer the first and second points are at least an order of magnitude more important than the third.

[1] https://en.wikipedia.org/wiki/Lazy_evaluation

No offense, but 'performance is not as important as...' is what basically all pro-FP devs say for years, still it seems that the rest of the world thinks exactly the opposite.

I make no claim about the importance of performance.

My claim is that the performance gains brought by lazy evaluation are far less important than the other gains it brings (because the performance gains it brings are rather small).

I'd agree that a lot of developers still over-index on performance though, probably because it's sexy and easy to measure.

To keep producing responsive compute programs as the complexity of those programs continues to rise while the single-core CPU performance remains steady, program performance must become more and more important.

It's true that there are also performance costs associated with laziness, but those weren't under discussion.

Conversely, I find it hard to achieve the same performance with strict code. I think it's likely a matter of familiarity.

>Haskell is notorious in my mind for being quite easy to write obscenely slow code in.

The standard prelude is flawed in many ways. Haskell 2020 will hopefully fix this. In the meantime: the recursion-schemes library might be of great use.

If you do not need to write notoriously slow code in Haskell, just don't do it. Use libraries (containers and mtl especially great), keep state strict (a handful of bang patterns).

I use Haskell's laziness with great success (look for paper "generating power of lazy semantics" it's fascinating; look "the essence of functional programming" for even more fascination). I use Haskell's flexibility with great success (how about beating C speed ten times? how about parallelization to all cores with couple lines of code?). It is really great language.

BTW, Haskell's RTS reuse chunk type field which is needed for implementation of laziness for synchronization and it is great! This means that it can provide everything that Java and/or .Net provides and get away with twice as less overhead for it.

It's a common concern but it's a terrible critique. Laziness has many subtle benefits, but everyone whines about it because its pitfalls are decidedly not subtle.

The benefits of laziness is difficult to appreciate if you are not used to it. For a great example of the benefits it brings, please read this:

http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...

A Haskell port of a logging library I'd originally written in Python ended up being almost 2 orders of magnitude slower than CPython 3, and almost 3 orders of magnitude slower than PyPy3.

PyPy3 resulted in performance similar to a barely-optimized C port.

https://codereview.stackexchange.com/questions/157118/a-port...

As was pointed out, GHC is calling getCurrentTime too often. If you take advantage of GHC's laziness, the value will stay valid longer. I assume that is what fast-logger does.

https://hackage.haskell.org/package/fast-logger

However we live in the real world and in the real world you cannot eliminate the concept of time, even in an abstraction such as functional programming. Therefore Functional programming is an utter lie.

Reasoning about the performance of a functional program is to peer through the lie and "reintroduce" time into this abstraction. This is why it it notoriously hard for functional programs to be reasoned about. Procedural programs are much more better for this in that regard.

Everything you wrote is somewhere between 90° and 180° wrong.

I've heard this a lot but still can't find a good code example to illustrate this. Any help?