If we're talking about categories, then we should be able to provide definitions of objects and morphisms clearly and independently. I guess I expected this to give denotational semantics of machine learning in an appropriately structured category, and then afterwards we can provide an implementation of these abstractions in Rust; however, this doesn't seem to be the case in this book. Rather, the category theory does seem somewhat stapled on. I wished that this would talk about things like Markov categories (or some other appropriate appropriate semantic domain) and then characterized machine learning algorithms via adjunctions between certain categories, such as in https://link.springer.com/article/10.1007/s44163-025-00707-w
As it's written, I don't see much of an opportunity for deriving theorems about the implementation from abstract nonsense, which, to me, would be the biggest strength of such a categorical description. This seems to be a simultaneous high-level introduction to Rust, machine learning, and category theory. The writing suffers from this, as the reader doesn't have much of an opportunity here to detangle these ideas from each other or see how one aids in understanding the others. Instead, they are all provide at once, and to an insufficient level of detail (for the amount of skimming that I did).
For example, the lambda calculus is the base for many useful programming languages. But the lambda calculus maps to a "closed Cartesian category". And many, many other interesting things in math can be mapped to a closed Cartesian category.
So now you can ask, "What if affine or linear logic were a programming language?" And the answer is, "You'd get a language with safe resource management, like Rust." Or you might ask, "What if probability were a programming language?"
Or on a smaller scale, a parameterized collection type with "map" is a functor. Add a single-element constructor and a "flatten" operation, and you have a monad. Functions with parameterized types are often natural transformations. And so on. This can then be directly analogized to constructs in different areas of math. Which might sometimes produce an interesting idea or two.
So category theory isn't always used to add something new and profound. Sometimes it's just a handy way to see something already there.
Without reading too much into what this framework does, I'd say category theory could be useful for some ML problems (i.e. layer composition, gradient propagation, etc.) - but I'd think it would be more useful as an analytical tool than as actual lib/code structures.
Edit: The more I read the more I think that this has at least been edited using AI. The number of instances of "this is not X, it is Y" is not super high, but it's higher than I'd expect from a human.
You use types to represent domain objects, and the program is composed of functions that transform domain objects into other domain objects.
Sure types are used a bit more aggressively than usual to restrict domains, particularly the newtype pattern (`struct TokenId(usize)` instead of just `usize`). But it doesn't look too exotic to me, or Category Theory influenced, other than in the sense that Category Theory terminology can be used to describe the structure of a regular typed program.
It's possible that I'm wrong and I'm missing the point. Frankly I really struggled reading this because of the AI generated vibe of the language, more than usual. I generally hate when content is criticised for just being AI generated, you can write very good and valuable things with AI by guiding it properly with authorial intent, but this one does really reek of bloated slop.
