I think it's experimental right now, but Idris (which I consider the "Child of Haskell"), has basic support for linear types [1], which could at least help the space-prediction problems. Doesn't hurt that Idris isn't lazy-by-default either.

My point is that I actually think that Idris could end up being successful in an industrial sense, due to the fact that it gives you all the correctness guarantees of Haskell (and more), but has managed to (thus far) avoid a lot of the cruft that has built up in the ~30 years Haskell has been around. Fingers crossed.

[1] http://docs.idris-lang.org/en/latest/reference/uniqueness-ty...

This stuff feels like a proof of concept that isn't really integrated to the rest of the language (Kinda like OCaml's OO). For example, it's unfortunate that Type, UniqueType and BorrowedType are different kinds (in Rust, they are the same kind; stuff that isn't "unique" just implement Copy)

Rust's advantage is that its borrow system, with reborrowing rules and such, feels much more ergonomic.

You're not wrong, but the fact that some work is being done on this is at least a good sign I think. A proof-of-concept is necessary before you can integrate these things organically into the language, and I that as a result it could be pretty interesting.

If I knew anything about elaborate type systems, I would try and address your complaints. Sadly, my knowledge of linear logic and whatnot is very ad hoc.

You're not wrong about unpredictability (to an extent), but the idea that Haskell is 'slow' has really got to go. Compared to languages commonly in use today, Python, Ruby, etc, Haskell goes like lightning with basic optimization (the kind C and C++ programmers are used to).

The fact is that, for the vast majority of workloads, which are not heavily algorithm dependent, idiomatic Haskell is going to be much faster than what most people are using. For the algorithm dependent ones, a Haskell programmer familiar with GHC's optimization layer should suffice to get very good performance. I've written several high performance Haskell programs, and it's moderately time consuming but not anymore difficult than other languages.

> idiomatic Haskell is going to be much faster than what most people are using.

I am not trying to be pedantic, but your point is moot if you consider what "most people" are using are not dynamically typed interpreted languages like Python Ruby or PHP, but rather statically typed, compiled languages like Java, C#, and C++. Java by itself dwarfs Python and Ruby combined.

IME, Haskell and Java are about on par, especially for basic things like http serving. Actually, Haskell is typically faster, because it compiles into much better machine code. That's just my experience as a professional Haskell developer. This is a combination of the fact that Haskell often compiles to really good machine code, and that Haskell is better at parallelization and multi-core workloads (async by default, for example).

Here are some benchmarks: https://github.com/jakubkulhan/hit-server-bench. As you can see, warp is on par, if not better than, many of the common JVM based options.

I'm not arguing Haskell is necessarily better than Java in all benchmarks (or C#). Merely that IME, most people dismiss Haskell as slow because it's a functional language, despite increasing evidence to the contrary. It is certainly capable of standing on its own against popular languages.

If Haskell allows you to express code as simple and correct at the expense of being fast, I think arguments can be made both ways as to whether or not that's a bug. If we accept the premise that the first two are more important than the last, then I think it follows that it's not a bug.

To your second point, I think the author is making an argument that it can perhaps even be earlier than that: the bug is introduced when the programmer's model of the behavior differs from reality. That is to say, the "bug" exists purely in the developer's mind. After that it's a matter of course for the bug to be transferred from there to the codebase.

If the developer chooses to interrogate their model before committing it to code, there is the possibility of the bug being caught before it ever makes it into the codebase. But perhaps it is still correct to say the bug still existed, for a short time, at least.

> the space and time performance of idiomatic Haskell code can be very surprising.

That is indeed one of Haskell’s drawbacks, though personally it’s one I am comfortable with given the alternatives. I’m happy for a program to be correct and less performant than fast and wrong. The performance issues are also not intractable. The tools for measuring this are pretty good.

I love Haskell, so I say this with all the love in the world, but the unpredictable nature of Haskell's performance actually can lead to incorrect code.

For example, due to laziness, file-streaming with lazy IO can end up with files being closed before you're done consuming. This is almost certainly never what you want, so Haskell's system actually hurt correctness.

In that particular case it's easy to get around if you use the Conduit library, but that's just one example.

I appreciate criticism like that, because it's helpful and valid. I happen to be aware of this and I do use Conduit often, but it certainly bears talking about. Haskell isn't a panacea, but I absolutely do not believe that all technologies are ultimately equivalent.

Oh, definitely don't disagree with you there (PG's article about the "Blub" language is one of my favorites); I definitely think that Haskell is one of the least-bad languages out there overall.

I will say that personally I have become somewhat enamored with Idris, but I think that most of the people that work on it claim that it is not production ready, and I've not used it for anything but personal projects. Still, I love that it gives me everything that I like about Haskell, and it's young enough to not have many of the drawbacks, at least not yet.

File streaming with lazy IO is widely considered an anti pattern though. So while your criticism was true in the past, we have very good and performant alternatives today