containers VS psqueues

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

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.

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

When I was first learning I did a bunch of leetcode/codewars to get familiar with the containers library and GHCI repl workflow. Then using Real World Haskell as a reference I implemented a few coreutils to play with IO.

A super-ugly Dijkstra implementation with psqueues for priority queues. Before I took them into use the first part took ~10 sec, after that it's ~60ms, and 2.5s for the second part. I believe, there's still room for optimization, but it's enough for today.