containers VS post-rfc

"Make invalid laziness unrepresentable" means you should use strict versions of container types instead of lazy ones. However, for better or for worse, sometimes the "strict version" of a data type is not actually a strict data type, it's just a strict API to the lazy type. Examples include Data.Map.Strict (not Data.Map or Data.Map.Lazy) or Data.HashMap.Strict (not Data.HashMap.Lazy) (sadly there is no Data.Sequence.Strict but perhaps there will be one day).

Indeed it's rather subtle. See https://github.com/haskell/containers/issues/752 for more discussion on the matter. Nonetheless, I believe it is "spine strict" in the sense that thunks for all values always exist, even if the spine that holds them can be rearranged due to laziness.

Note that the list index operator has O(n) complexity. Ideally you'd want to use something like Seq from the containers package

Edison and containers both have sequence types that support efficient, cons, snoc, viewL, viewR, append, map, and length.

containers

Calling linked lists Haskell's "primary data structure" seems off-base to me. Yes, there's String, yes, there's built-in syntax for List... but there's also everything in containers, and vector is pretty easy to use in practice, though it would probably be good for more learning material to mention it more prominently.

Haskell has much more sophisticated immutable data structures, you can find them in the "containers" package: https://hackage.haskell.org/package/containers

I asked this on the libraries mailing list but thought posting here would bring in potentially more responses. I made a recent change to the behaviour of lookup and find (see here for more details: https://github.com/haskell/containers/pull/800).

Rust has nothing on Haskell. containers, which might as well be considered part of the standard library, has been out for almost 14 years and is still 0.x

That's what it's best for, but personally I use it for everything. If I ever get into low-level code I'll probably use Rust though.

You can confirm that parsers/tokenizers is ranked "best in class" here though:

https://github.com/Gabriella439/post-rfc/blob/main/sotu.md

Note that this is ported from here: https://github.com/Gabriella439/post-rfc/blob/main/sotu.md which comes with more exposition.

State of the Haskell Ecosystem

According to State of the Haskell ecosystem, Haskell is THE language of choice for implementing compilers, and THE language of choice for writing parsers. Thus, it is not surprising to see more Haskell projects from those particular categories than from other categories.

This is great for understanding what libraries to use in the Haskell ecosystem: https://github.com/Gabriella439/post-rfc/blob/main/sotu.md

In particular, I got comfortable reading hackage documentation to understand quickly how to use libraries (aeson, megaparsec, mtl, pipes, etc), got comfortable with the ecosystem (this helped: https://github.com/Gabriella439/post-rfc/blob/main/sotu.md), got comfortable with the main language idioms and features (https://smunix.github.io/dev.stephendiehl.com/hask/tutorial.pdf) and got comfortable with simple things that for some reason had confused me before (case, \case, let).

Gabriella Gonzalez has a great doc that is reasonably up-to-date, sounds similar to what you're looking for? https://github.com/Gabriella439/post-rfc/blob/main/sotu.md

With that being said, Python is without a doubt the best option, and I'd also be very interested to read the articles you found that say that Python is not a good choice because it's been the industry standard for a long time now. Data science and machine learning are one of the areas where the Haskell ecosystem is not as strong as other languages, but libraries and tools do exist. There's a great list of Haskell resources by domain here, and as you can see, there are Haskell bindings to tensorflow and pytorch, along with other libraries that support common data science programming.