Safer paths, part 2 - Stop, Reconsider, Contribute

Date 2016-08-21

Last week I published a paths library. I showed it to the Haskell subreddit and learned from their reaction.

With good intentions I set out to create a safer way to handle paths in Haskell. After a few days of coding and lots of testing, I had a first draft of a solution. Some polishing later, I put it up on Hackage, wrote a blog post about it and put the blogpost up on reddit.


I got very reasonable not-so-positive reactions. The main reaction pointed me to the path library. This library solves the same problem (and does it better) and is much more widely used. Subsequent reactions made me reconsider what made safepath different in the first place. I decided to stop work on safepath for now.


There are aspects in which path is superior to safepath. Most notably: it performs better, is already widely used and has some more advanced safety features. The biggest (and arguably only) advantage of safepath was that safepath is tested much more thoroughly.

If I was going to make safepath better than path, I was going to have to copy a lot of features and then convince people to start using safepath instead of path in the future. It would have been a lot of extra work, just for a more thoroughly tested safe paths library.

That is why this post's title is not "Safer paths, part 2 - safepath IO operations" as I had planned last week.


Instead of stubbornly continuing work on safepath, I am currently trying to contribute tests to the paths library. You can follow the progress here. When this is done, I will deprecate safepath and point any users towards path instead.

Poop deprecation and shitty code

Looking for a lead engineer?

Hire me
Safer paths, part 1 - valid and typed paths