I just noticed that I avoid using ByteStrings because I tend to spend a
huge amount of time reading GHC output and trying to figure out if I
am/should be using the strict or the lazy version. I have to use both
lazy/strict because different libraries use different versions. Maybe
having different names would have helped.
Am I doing something wrong or is the interface to ByteStrings a poor design?
My gripe with ByteString is that there are two distinct ByteString types
disguised as one. There are “disguised” simply by having the same name.
This leads me to think the use of ByteString will be simpler than it
usually turns out to be. I fear Backpack may soon make this worse.
Obviously, this is not exclusive to ByteString. Using the same name for
strict and lazy versions is all over the place. Here is another example:
But the problem is specially insidious with BytStrings because of their
usage patterns and also because the process of finding out which version
is which through GHC error messages is very inefficient.
Here is a very ugly example where I believe I was misled by both
ByteString types having the same name.
I needed to make a “random looking but secretly not random” number and
package it up in a 128-bit UUID. In other words, I wanted to mark the
random numbers I create, but in a way that nobody else knows they are mine.
The `hash` function from the cryptonite library accepts ByteString and
its output can be converted to ByteString.
The UUID type also has a function `fromByteString`.
What could be easier?