Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

They are just not bounds checked. That is not "writing C in Haskell".

>binary-trees uses artificial strictness for the sake of the benchmark

What on earth is "artificial strictness"? Forcing evaluation when you need something to be evaluated immediately is not artificial, not unidiomatic, and not "writing C in Haskell".

>Nine of the ten Haskell implementations are demonstrations of writing C in Haskell

And end up shorter than rust? The idea that writing lower level code is "writing C in haskell" is nonsense, the ability to write more verbose but faster code is not harmful, it is useful. But the fact that lower level haskell is still shorter than rust and yet you want to act like it is some sort of horrible thing makes it hard to believe that you are really concerned about the horrors of writing slightly more verbose code.

Using strict evaluation when appropriate is most certainly idiomatic Haskell code.

> Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).

This (C in Haskell accusation) is debatable, though I'm not sure there's much to be gained even given a totally successful discussion where we both communicate our points 100% effectively.

No, the point was that it is "far from idiomatic". Did you read the post I was replying to?

How is it not? That is a complete non-sequitur and makes no sense. What sort of definition of functional programming are you using that you think it restricts what data types you are allowed to use? Do you think you aren't allowed to use lists in C?

>In "Real World Haskell" they advise you to forgo of arrays

You might want to read it instead of misrepresenting something out of context. You might also wish to consider that many of the haskell shootout submissions came from the authors of RWH.

The normal definition of functional programming, in which not all data structures used in imperative programming are idiomatic (or even considered "functional").

For starters, mutable data structures would be considered not purely functional. E.g:

"Most books on data structures assume an imperative language such as C or C++. However, data structures for these languages do not always translate well to functional languages such as Standard ML, Haskell, or Scheme. This book describes data structures from the point of view of functional languages, with examples, and presents design techniques that allow programmers to develop their own functional data structures" [1]

[1] http://www.cambridge.org/us/academic/subjects/computer-scien...

And yet, the programs don't all perform the same.

One regex task doesn't tell you much of anything because so much can be different with a different task. Then again, people are usually surprised by V8 and Irregexp.

The GHC version has been updated so many times since the last programs were contributed, that I hope the code would look better if it was written to use the latest greatest Haskell.

I mean: it's not like the specific problem domain needed a "less commonly used function" (e.g. you need a function to do X, where X is something that you rarely need to perform).

Rather it's: "we need to code A, but we will use less commonly used functions instead of what we'd normally use for A, just to get more performance".

Plus, it's not like you merely exchange function f with g, while all other factors stay the same. The choice of those "less commonly used functions" also affects other aspects of the program's design (e.g. making it into a more imperative style, going for unsafe, opting for mutability, etc).

So the interesting question to call it idiomatic or not, for me, is:

"If ultimate performance wasn't a factor, would a Haskell programmer write this program in the same way?"