Remove some embarrassing humor from the alternatives docs

Author: Veetaha

website/src/guide/alternatives.md

@@ -87,33 +87,32 @@ Line::builder().x1(1).y1(2).x2(3).y2(4).build(); // [!code error]
 
 There are two problems with `#[derive(Builder)]` syntax in this case:
 
-1.  This refactoring becomes a breaking change to `Line`'s builder API 😢.
-2.  The private utility `Point` type leaks through the builder API via `point1`, and `point2` setters 😭.
+1.  This refactoring becomes a breaking change to `Line`'s builder API.
+2.  The private utility `Point` type leaks through the builder API via `point1`, and `point2` setters.
 
 The fundamental problem is that the builder's API is _coupled_ ⛓️ with your struct's internal representation. It's literally `derive`d from the fields of your struct.
 
 ### Suffering
 
 If you were using `typed-builder` or `derive_builder`, you'd be stuck for a while trying to find the magical 🪄 combination of attributes that would let you do this change without breaking compatibility or leakage of the private `Point` type.
 
-With no solution in sight 😮‍💨, you'd then fall back to writing the same builder manually. You'd probably expand the builder derive macro and edit the generated code directly, which, ugh... hurts 🤕.
+With no solution in sight, you'd then fall back to writing the same builder manually. You'd probably expand the builder derive macro and edit the generated code directly, which, ugh... hurts.
 
-However, that would be especially painful with `typed-builder`, which generates a complex typestate that is not human-readable and maintainable enough by hand. It also references some internal `#[doc(hidden)]` symbols from the `typed-builder` crate. Achoo... 🤧.
+However, that would be especially painful with `typed-builder`, which generates a complex typestate that is not human-readable and maintainable enough by hand. It also references some internal `#[doc(hidden)]` symbols from the `typed-builder` crate.
 
 ::: tip
 
-In contrast, `bon`'s type state **is** human-readable, maintainable, and [documented](./typestate-api) 👍
+In contrast, `bon`'s type state **is** human-readable, maintainable, and [documented](./typestate-api)
 
 :::
 
 ### Behold the Function-Based Builder
 
-This change is as simple as pie 🥧 with `bon` or `buildstructor`. The code speaks for itself:
+This change is as simple as pie with `bon` or `buildstructor`. You need no more derives on a struct. Its internal representation can be decoupled from the builder by deriving the builder from a method:
 
 ```rust
 use bon::bon;
 
-// No more derives on a struct. Its internal representation is decoupled from the builder.
 pub struct Line {
     point1: Point,
     point2: Point,
@@ -139,19 +138,15 @@ impl Line {
 Line::builder().x1(1).y1(2).x2(3).y2(4).build();
 ```
 
-Ah... Isn't this just so simple and beautiful? 😌 The fun part is that the constructor method `new` that we originally abandoned comes back to heroically save us ⛑️ at no cost, other than a star ⭐ on `bon`'s [Github repo](https://github.com/elastio/bon) maybe 🐈?
-
-And you know what, our old friend `new` doesn't feel offended for being abandoned. It doesn't even feel emotions, actually 🗿. But it's happy to help you 🫂.
-
-Moreover, it offers you a completely new dimension of flexibility:
+Moreover, this approach offers you a completely new dimension of flexibility:
 
 -   Need some validation? Just change the `new()` method to return a `Result`. The generated `build()` method will then become fallible.
 -   Need to do an `async` operation in the constructor? Just make your constructor `async` and your `build()` will return a `Future`.
 -   Need some adrenaline 💉? Just add `unsafe`, and... you get the idea 😉.
 
 ---
 
-The chances of hitting a wall with function builders are close to zero, and even if you ever do, you still have access to the [Typestate API](./typestate-api) in `bon` for even more flexibility 💪.
+The chances of hitting a wall with function builders are close to zero, and even if you ever do, you still have access to the [Typestate API](./typestate-api) in `bon` for even more flexibility.
 
 ## Generated Docs Comparison