I agree. The only languages I've used that are remotely competitive for my purposes are static JVM languages (Java and Scala), Ocaml, and Julia for array ops. Haskell comes closer than many others, but just isn't there yet.
The docs you linked to are a 3'rd party package marked "experimental". I'll also suggest that you are glossing over most of the difficulties in using them. It's trivially easy to call `unsafeRead`. It's not so easy to wrap your operations in the appropriate monad, apply all the necessary strictness annotations to avoid thunks, and properly weave this monad with all the others you've got floating around.
(That last bit is fairly important if you plan to write methods like `objectiveGradient dataPoint workArray`.)
Except scala and ocaml are both slower than haskell.
>The docs you linked to are a 3'rd party package marked "experimental".
No it is not. What is the point of just outright lying?
>I'll also suggest that you are glossing over most of the difficulties in using them
I'll suggest that if you want people to believe your claim, then you should back it up. Show me the difficulty. Because my week 1 students have no trouble with it at all.
>It's not so easy to wrap your operations in the appropriate monad
You are literally saying "it is not easy to write code". That is like saying "printf" is hard in C because you have to write code. It makes absolutely no sense. Have you actually ever tried learning haskell much less using it?
>apply all the necessary strictness annotations to avoid thunks
All one of them? Which goes in the exact same place it always does? And which is not necessary at all?
>and properly weave this monad with all the others you've got floating around.
Ah, trolled me softly. Well done.
I also don't know why you are behaving as if I dislike Haskell. I enjoy Haskell a lot, I just find getting very good performance to be difficult. You can browse my comment history to see a generally favorable opinion towards Haskell if you don't believe me.
I also gave you a concrete example of a reasonable and necessary task I found difficult: specifically, numerical functions which need to mutate existing arrays rather than allocating new ones, e.g. gradient descent. Every time I've attempted to implement such things in Haskell, it takes me quite a bit of work to get the same performance that Scala/Java/Julia/C gives me out of the box (or Python after using Numba).
This is a bit of a strange convention in the Haskell world. Libraries tend to be marked "experimental" even when they are completely stable and the correct choice for production use. Note that Data.Text is also marked "experimental", and it is perfectly stable and the correct choice for Unicode in Haskell.
> 3'rd party package
Data.Vector is 3rd party in the sense that it is not part of the GHC base package, but so what? It is now considered the correct library for using arrays in Haskell.
I'm not. Given that you can't tell someone's emotional state via text, it doesn't make much sense to assume an emotional state for someone else simply because it will make you feel better.
>The page you linked to explicitly says "Stability experimental"
So does every library. It is the default state of a seldom used feature that still hasn't been removed.
>I also don't know why you are behaving as if I dislike Haskell
I am responding to what you say. You said using a mutable unboxed array is hard. That is not a simple misunderstanding, that is either a complete lack of having ever tried to learn haskell, or a deliberate lie. There's literally no other options. I teach people haskell. They do not use lists for anything other than control. They have absolutely no problem using arrays.
>I also gave you a concrete example of a reasonable and necessary task I found difficult
But you didn't say what made it difficult. So a reader is left to assume you are trolling since that task is trivial.
The Haskell community has historically had a reputation as a welcoming and friendly community. Let's work on presevering that.