I already found some pretty solid options for movies (Letterboxd) and video games (Backloggd), but books have been a bit of a struggle. In this post, I want to document this struggle a bit. Hopefully, this can help anyone in a similar situation.
Comparing different solution is always kind of pointless when you don't know how you are comparing them or what exactly it is you want. Luckily, given my experience with other sites, I've got a pretty good idea as to what I want, namely:
The StoryGraph was, I think, the first site I went to after leaving Goodreads. It's also, from what I can tell, the most popular alternative, which is a plus. So let's go over each of my requirements and evaluate how fully they are realized.
Interestingly enough, this, in my opinion, where The StoryGraph is weakest. While, in theory, the building blocks are there (you can write reviews, they are shown to people, they can like them, and you can sort by most liked), this feature feels basically hidden.
On the front-page of a book, you can only see the average rating of the book; again, you have to go out of your way to see any more details, like the rating distribution or any written reviews. I have to assume that this is also why I haven't seen many reviews with more than five likes and none with more than ten – nobody reads them! Anecdotally, I can also confirm this because on both The StoryGraph and Fable, I posted the exact same reviews for two books. On the former, I have gotten absolutely no interactions from those, whereas on the second, I received three likes on one and a few follows within just a few days.
To make matters worse, The StoryGraph appears to have, on average, the least interesting, shallowest reviews of any of the sites I've tried. Again, I can only speculate as to why this is. Some of it must be my previous observation of reviews kind of being hidden. Maybe it's also because, philosophically, the site is very much designed to be "data-driven" (more on that later), so people that are more interested in organic interactions don't stick.
I already mentioned how The StoryGraph feels very "data-driven". By that I mean that it appears to try to make book ratings "more objective" by focusing on some select statistics, rather than individual reviews.
And I kind of hate it. The spectrum of what books can offer is WAY too vast as to be captured by a few tags, moods, genres, and six weird metrics. I especially dislike the metrics – "Pace", "Plot or character driven?", "Strong character development?", "Loveable characters?", "Diverse cast of characters?", and "Flaws of characters a main focus?". They feel like they were specifically designed for one or two genres (namely genre fiction and romance) that focus way too much on the "plot". Like, why is there nothing about the prose? Or whether the book is trying to say something or just wants to be entertaining? And they are really vague! For example, a "diverse cast of characters" can mean a lot of different things to a lot of different people.
But if you think about it, this plot / story focused approach makes a lot of sense for a site with "story" in its title. Guess it's just not for me.
During my exploratory phase with Mastodon around two and a half years ago, I also moved from The StoryGraph to bookwyrm.social, the flagship, and largest, instance of BookWyrm. Just like Mastodon (or E-Mail), it is federated, meaning anyone can set up an instance for people to join whilst being able to interact with people from other instance.
Unfortunately, the fact that BookWyrm is a volunteer-run open-source project means that it doesn't have nearly as much funding as many other options, which in turn means fewer features.
Unsurprisingly, given that this is one of the most niche ways to track your books, you'll find few to no reviews on any given book, especially if they are a bit older and/or less popular. However, I did find that, on average, the reviews that do exist are very high quality. They tend to be quite long and detailed, and you don't have to sift through "reviews" with no text to get to those that actually contain a human's thoughts.
Unfortunately, liking reviews doesn't appear to really do anything(?) – you cannot, for example, sort a book's reviews by rating. You can't even see how many people liked one.
Also, you cannot see the distribution of rating; you are only shown the average. This makes that number pretty much useless – a 3.5 / 5, for example, could indicate a mediocre book or a divisive one (with both very positive and very negative reception). Without a distribution, you're basically back to guessing.
bookwyrm.social can, at times, be pretty slow to load and react. I assume that is due to running on volunteer-run hardware with minimal budget. Maybe other instances are better, though.
Also, there are lots of paper-cuts to be found; this is definitely not a very polished product. For example, the search is really finicky with basically no optimization (searching for the way of igs will get you no results). Also, there are lots and lots of duplicates, both for books and authors. Annoyingly, different copies of the same book will usually link to different copies of the same author and some of the latter may only have a small subset of their works linked.
I'll break with the formula here and cut this short: Fable seems like a really promising option with a heavy focus on social reading. However, there are some pretty glaring issues that make me not want to use it. Namely, it feels like a walled garden (with impressively high walls at that). There is no option to export your collection, and apparently, there are no plans of adding one. There is absolutely no way to interact with anything on the site without an account; can't even browse books. And, to add insult to injury, essentially the only way to interact with the service is through their app – the website version is extremely bare-bones and allows you to do little more than view your own profile.
So yea, no thanks. The entire point of this exercise was to avoid closed ecosystems like this.
I should preface this with noting that I have used Hardcover only for a little bit in order to get a feel for them. However, I tried simulating relatively realistic usage by intentionally not import my data from anywhere and instead adding a subset of my read books and reviews manually.
Apart from BookWyrm, Hardcover is definitely has the smallest community of the options I have explored so far. Going by their 2025 recap, they grew from 25 thousand users to 60 thousand in that year, which is definitely an impressive growth rate. But in comparison to The StoryGraph, which just recently surpassed 5 million users, that is still tiny. But 60 thousand is still plenty, I think.
csv.All of the essentials appear to be present. You can follow people, which puts them in a feed that shows you their recent activities. This feed is also pretty central to your home-page, giving you an overview of the most recent activity at a glance.
I quite like the prompt feature they've got, which lets you answer a shared prompt with a collection of books and an explanation as to why you put them there. As a software engineer, I love a good abstraction and this is an awesome way of taking the "what are your favorite books" section of the profile and extend it to other applications.
A particularly fun feature of user profiles is that you can sort other people's lists by your ratings. I've never seen that feature before but I will definitely be making use of it here.
On that note, reviews are sorted by the number of their likes by default, which I appreciate, but there doesn't appear to be any other way to sort them; you can just filter by a specific rating range. Still, this is a sensible default and probably good enough for me.
As an aspiring blogger, I love the fact that you can add a canonical URL to your review. I haven't seen any reviews using that feature though, so it's either not used much or really not all that visible.
Also, as probably became obvious from the section on The StoryGraph, I despise recommendation algorithms. Thus, I was pleasantly surprised when I found out that the Explore section consists of a bunch of different ways of browsing books, lists, users, etc.
Another pleasant surprise was the fact that Hardcover appears to be low on trackers and web nonsense. I've got set up my uBlock to block all third-party JavaScript scripts and the site works just fine without me needing to allowlist anything. Kudos!
I am honestly a bit shocked that this journey / rabbit hole appears to have come to an end, especially so soon. I still had quite a few other options on my list to check out, like LibraryThing, Tome, Oku, Literal.club, Papertrail, or BookSloth. But after checking out what all these sites have to offer, and how they don't fit my needs (apart from Hardcover), I am honestly getting a bit tired of this topic and am definitely quite satisfied with Hardcover.
This may not be the "optimal" choice; there may be another service out there that does everything that Hardcover does and more and / or better. But there is this little saying you may have heard: Perfect is the enemy of good. Admittedly, looking at my past actions and decisions, I certainly don't appear to have heard of it, or, if I did, I must be choosing to ignore it.
I hope this silly overview of book rating websites that was somehow both way too detailed and also way too narrow may be of help to someone else. It was definitely helpful for me. See you on Hardcover! :)
Target audience: Anyone interested in functional programming and relatively new to it; I won't assume any knowledge about it.
For this series of blog posts, I want to clear up some common misconceptions I've seen people make whilst they are first learning about functional programming, and the "map, filter, reduce pattern" in particular. These basically boil down to "I can achieve the same thing with a for-loop / list-comprehension".
A good example of this is ArjanCodes' video on map and filter, which primarily compares directly replacing loops and if-statements with map and filter.
I see two perspectives that are missing from these analyses, both of which I will be going into more depth in my follow-up blog posts:
map, filter, reduce is a way of thinking that is easily extended onto more complex problems.
There is a whole family of functions that are just about acting on data in a structured way.
Alternative approaches like for-loops and list-comprehensions don't really work like this; they are a one-size-fits-all solution.map, filter, and reduce are functions, so they can be manipulated using functional techniques like partial function application and data processing pipelines; they are first-class citizens in functional languages.
for-loops and list-comprehensions are syntax and second-class citizens in most languages.For code examples, I'll be using Python. The reason for this is that, even though I personally don't really like Python, I'm pretty comfortable with it, it's got decent support for functional programming, and most people should be able to read it relatively well. I'll also add some basic type-hinting to all of my examples. It should be pretty safe to ignore these if you want, especially since later on they will get a bit more involved.
map, filter, reduce?
Just so we are all on the same page, I want to dedicate the rest of this introductory post to defining these operations I've been talking about. In short, map, filter, and reduce are functions that allow us to act on collections of values "all at once". Each is an example of a higher-order function, meaning that they take another function as an argument. This may seem a bit weird at first but is actually an extremely powerful idea. In object-oriented programming, you may call this a strategy pattern.
Feel free to skip this if you are already familiar with these operations.
map
map is probably the easiest to understand of the bunch. In the simplest case, it takes
f with one argument and some kind of return value andcoll of values
and returns a new collection where f was applied on each value in coll.
# the function we want to apply
def f(x: int) -> int:
return x * 2
coll = list(range(10))
print("original: ", coll)
# in python, `map` is lazy; we have to convert its result to a list to actually see it
print("no list conv: ", map(f, coll))
print("mapped: ", list(map(f, coll)))
original: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] no list conv: <map object at 0x1001f41f0> mapped: [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
Notice how, after applying map, the shape of the given collection does not change, only its contents do.
We can achieve the same effect using list-comprehensions:
print("list-comprehension:", [f(x) for x in coll])
list-comprehension: [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
At the beginning, I said "in the simplest case" because map actually works with functions of any arity. For example, we could add two sequences of numbers pair-wise using the following code:
# in python, there is no function for adding two numbers,
# so we have to define our own.
# (well technically there is, in the `operator` module, but I'll still define it here)
def add(x: int, y: int) -> int:
return x + y
another_coll = list(range(10, 20))
print("mapped:", list(map(add, coll, another_coll)))
mapped: [10, 12, 14, 16, 18, 20, 22, 24, 26, 28]
Again, we can achieve the same thing with a list comprehension, though this time, we have to use zip in order to create the pairs we want to act on:
print("list-comprehension:", [add(x, y) for x, y in zip(coll, another_coll)])
list-comprehension: [10, 12, 14, 16, 18, 20, 22, 24, 26, 28]
filter
filter, as the name suggests, lets us filter out values from a collection. Thus, where map lets us transform values in a collection, filter lets us transform the shape of the collection itself without touching the values.
It, too, takes two arguments:
p that takes a single argument and returns either True or False (this is often called a predicate function, or simply predicate).
It is used to indicate whether or not to keep a specific value.coll of values.# the predicate that indicates whether we should keep values
def p(x: int) -> bool:
return x < 10
coll = list(range(0, 20, 2))
print("original: ", coll)
# in python, `filter` is also lazy.
print("filter object: ", filter(p, coll))
print("filter: ", list(filter(p, coll)))
# again, we can achieve the same effect with a list-comprehension
print("list-comprehension:", [x for x in coll if p(x)])
original: [0, 2, 4, 6, 8, 10, 12, 14, 16, 18] filter object: <filter object at 0x105404190> filter: [0, 2, 4, 6, 8] list-comprehension: [0, 2, 4, 6, 8]
Because both filter and map are lazy, they can be used well in conjunction, allowing us to only act on the data we actually want to:
above_10 = filter(lambda x: x > 10, coll)
multiplied = map(lambda x: x*3, above_10)
even = filter(lambda x: x % 2 == 0, multiplied)
# use `print` to illustrate that the last `map` doesn't "see" all data
printed = map(print, even)
list(printed)
36 42 48 54
This also lets us work with extremely large (or even infinite) sequences without any issues (as long as we limit the number of results we want at any point):
from collections.abc import Iterable
def mk_infinite_numbers() -> Iterable[int]:
i = 0
while True:
yield i
i = i + 1
def is_even(x: int) -> bool:
return x % 2 == 0
def power_of_two(x: int) -> int:
return 2 ** x
def starts_with_1(x: int) -> bool:
return str(x)[0] == "1"
def take[T](n: int, seq: Iterable[T]) -> list[T]:
"""Return the first `n` values from a (possibly infinite) sequence."""
return [next(seq) for _ in range(n)]
infinite_numbers = mk_infinite_numbers()
evens = filter(is_even, infinite_numbers)
even_powers_of_two = map(power_of_two, evens)
that_start_with_1 = filter(starts_with_1, even_powers_of_two)
print("first 10:", take(10, that_start_with_1))
print("next 10:", take(10, that_start_with_1))
first 10: [1, 16, 1024, 16384, 1048576, 16777216, 1073741824, 17179869184, 1099511627776, 17592186044416] next 10: [1125899906842624, 18014398509481984, 1152921504606846976, 18446744073709551616, 1180591620717411303424, 18889465931478580854784, 1208925819614629174706176, 19342813113834066795298816, 1237940039285380274899124224, 19807040628566084398385987584]
reduce
reduce is by for the most difficult to understand (and also most powerful) operation of the three. While the first two capture how me may change the shape and contents of a collection, returning a new collection, reduce allows us to aggregate collections into completely new kinds of data.
There are some different definitions of what exactly reduce requires floating around. I'll use the strictest one, often also called fold, which is a function that takes three arguments:
f with two arguments: the current aggregated value agg and the new value x to aggregate.coll of values to aggregate.agg.
I haven't really explained what "aggregating" means in this context. Roughly speaking, this refers to the idea of incrementally updating a value with new information. This may be something as simple as computing a sum, or as complex as managing the current state of a game, given the collection of all player inputs. Strictly speaking, we can even define map and filter in terms of reduce, but I'll leave that as home-work for the reader ;)
coll = list(range(1, 11))
print("original:", coll)
# in python, `reduce` is not in the global namespace.
# we have to import it from the builtin `functools` library.
from functools import reduce
print("sum, using reduce:", reduce(add, coll, 0))
original: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] sum, using reduce: 55
Now this is where trivial alternatives start getting more difficult to come by. Of course, in Python, we could use the sum function for this. But if we didn't have that, we would start using for-loops and variable overriding (something we would want to avoid when writing programs in a functional style).
print("sum, using sum:", sum(coll))
def my_sum(coll: list[int]) -> int:
current_sum = 0
for x in coll:
current_sum = current_sum + x
return current_sum
print("sum, using for-loop:", my_sum(coll))
sum, using sum: 55 sum, using for-loop: 55
As for a less trivial example, let's calculate the cumulative sum, using reduce and a for-loop (we could also use itertools.accumulate, but that's effectively just a lazy reduce in this case):
# we'll just use the previous collection this time
def cumsum_increment(agg: list[int], x: int) -> list[int]:
new_value = agg[-1] + x
return agg + [new_value]
print("cumsum, using reduce:", reduce(cumsum_increment, coll, [0]))
def cumsum_using_for(coll: list[int]) -> list[int]:
cumsums = [0]
for x in coll:
new_value = cumsums[-1] + x
cumsums = cumsums + [new_value]
return cumsums
print("cumsum, using for-loop:", cumsum_using_for(coll))
cumsum, using reduce: [0, 1, 3, 6, 10, 15, 21, 28, 36, 45, 55] cumsum, using for-loop: [0, 1, 3, 6, 10, 15, 21, 28, 36, 45, 55]
You may noticed some similarities between the two approaches. This is how we could implement reduce using a for-loop:
def my_reduce(f, coll, initial):
agg = initial
for x in coll:
agg = f(agg, x)
return agg
As a bonus, I'd like to highlight a way we can implement the cumulative sum above by re-using the add function we defined previously. This solution is also more general, allowing us to cumulatively aggregate any kind of operation we may want to do with reduce (e.g. to keep track of the entire history of our game, so we can time-travel).
For this, we will be defining a new higher-order function that takes an "aggregator" function like above and turns it into one that returns a list of all of its results. For higher-order functions, type-hints can get a bit much, unfortunately, so I separated the two.
def cumulative_aggregation(f):
def wrapped(agg, x):
return agg + [f(agg[-1], x)]
return wrapped
Then, we can use it to calculate our cumulative sum:
print("cumsum, using function composition:", reduce(cumulative_aggregation(add), coll, [0]))
cumsum, using function composition: [0, 1, 3, 6, 10, 15, 21, 28, 36, 45, 55]
Now, we can trivially do the same thing using any other aggregator function, like subtraction:
def minus(x: int, y: int) -> int:
return x - y
print("total difference:", reduce(minus, coll, 0))
print("cumulative difference:", reduce(cumulative_aggregation(minus), coll, [0]))
total difference: -55 cumulative difference: [0, -1, -3, -6, -10, -15, -21, -28, -36, -45, -55]
As promised, here's the type-hinted version, using Python's new syntax for generic types:
from collections.abc import Callable
def cumulative_aggregation_typed[Agg, X](
f: Callable[[Agg, X], Agg]
) -> Callable[[list[Agg], X], list[Agg]]:
def wrapped(agg: list[Agg], x: X) -> list[Agg]:
return agg + [f(agg[-1], x)]
return wrapped