anchor.diff:      (http/ok promise {:content-type "text/plain"})))
   ----
   
  -Thanks to the *futura* library internals, we can use it with
  -link:https://github.com/funcool/cats[cats] `mlet` macro, that allows us structure pure
  -async code in a synchronous way:
  -
  -[source, clojure]
  -----
  -(require '[futura.promise :as p])
  +Thanks to the link:https://github.com/funcool/cats[cats] `mlet` macro, that allows us
  +structure pure async code in a synchronous way:
  +
  +[source, clojure]
  +----
  +(require '[promissum.core :as p])
   (require '[cats.core :as m])
   
   (defn my-async-handler
  
positive.code: 
  [source, clojure]
  ----
  (require '[futura.promise :as p])
  
  (defn my-async-handler
    [context]
  
negative.code: [[difference-with-aleph]]
  === What is the difference between _catacumba_ and Aleph?
  
  First of all, Aleph is one of the most robust libraries in the Clojure ecosystem for
  building asynchronous servers. Here is an incomplete list of differences and motivations
  why I wrote _catacumba_ instead of using _aleph_ directly in my applications:
  
  - Aleph with manifold offers good abstractions for creating async servers but they are
    much too low level and only provide the basic building blocks. _catacumba_ intends to be
    a toolkit that is highly focused on web development by providing a good collection of
    features that matter to web developers.
  - I wrote _catacumba_ to have an alternative to ring and _Aleph_ that uses ring's
    abstractions for handling web requests.
  - Aleph has a good path to have an easily readable  and user friendly documentation.
  - Aleph is build on manifold streams and _catacumba_ uses reactive-streams abstractions.
  