DEV Community: Dani Bengl

Exploring Rust: A Rubyist's Perspective

Dani Bengl — Fri, 28 Feb 2025 21:24:18 +0000

At Renuo, we love Ruby. It's simple, elegant, and powerful. But let's be honest, Ruby isn't the fastest language out there.

Over the last couple of months, I've been exploring low-level programming, hoping to bridge the gap between the high-level world of Ruby and the lower-level world of systems programming. To do this, I started working on my first Rust project: a blazingly fast voxel "game" called rsmc. It features a terrain generator, meshing, a scalable client-server architecture, and custom serialized messages for high-speed communication. This project has been my playground for learning Rust, and in this post, I'll share some of the lessons I've learned along the way.

Why Rust?

Rust is one of the most appreciated programming languages, as highlighted in the GitHub Octoverse Survey. It offers memory safety, high performance, and strong tooling, making it a solid choice for both small utilities and large-scale applications. Many of the tools I use daily, like Alacritty and 1Password, benefit from Rust's speed and reliability.

Key Benefits

Performance: Comparable to C and C++, but with safety mechanisms that prevent common errors.
Memory safety: Eliminates null pointer dereferences, segmentation faults, and data races.
Modern syntax: Readable and expressive, making it accessible despite its low-level capabilities.
Powerful tooling: Cargo simplifies dependency management, builds, and testing.

For my voxel game, Rust's speed and safety make it an excellent choice for terrain generation, networking, and real-time interactions. Unlike dynamically typed languages such as Ruby, Rust catches entire categories of bugs at compile time, improving maintainability.

Beyond CLI tools, Rust powers game engines, operating systems, simulations, and even web browsers, proving its adaptability across different domains.

Bevy: Game Development Made Fun

Since my project is built with Bevy, understanding its core concepts was very important. Bevy's entity-component-system (ECS) architecture makes game development modular and efficient, allowing for highly decoupled systems.

Some of my favorite takeaways:

Systems: Keep them small and focused on one task. This way they are easier to test and extend.
Plugins: Encapsulate resources, systems, and components into distinguishable modules.
Events: Use events to the fullest extent to decouple systems and keep code modular.
States: Run systems only when they are relevant (e.g., Menu, Playing). This helps with UI and logic separation. In particular this PR: #32

Bevy makes structuring a game engine intuitive, and its Rust-first approach ensures safety and performance while keeping things flexible. If you're interested in learning more about the ECS approach to game development, I wrote a blog article about planning an ECS: Multiplayer in Rust Using Renet and Bevy.

Feature Flags: Shipping Less in Production

Feature flags allow enabling or disabling specific functionality at compile time, making it easy to toggle features based on configuration.

In my voxel game, feature flags help manage debugging tools like wireframe rendering and debug UI. What's neat about these feature flags is that debug code doesn't get shipped in production, reducing binary size and keeping the release build clean.

In Cargo.toml, you can define feature flags like this:

[features] 
egui_layer = []
terrain_visualizer = ["egui_layer"]
renet_visualizer = ["egui_layer"]`

And then use them in your code:

#[cfg(feature = "egui_layer")] {   
use bevy_inspector_egui::bevy_egui::EguiPlugin;
    app.add_plugins(DefaultPlugins);
    app.add_plugins(EguiPlugin);
}

The downside is that testing all possible feature combinations is a challenge. With just five features, you already have 32 different configurations to check. But that's the price of flexibility.

Cargo Watch: Automating Workflows

During the development of rsmc, I often needed to recompile code, and manually restarting my binary after every change quickly became tedious. I really wish I had discovered cargo-watch earlier.

Just install it and let the watcher do its thing:

cargo watch -x 'run --bin client'

Composition Over Inheritance

Coming from Ruby, where inheritance is common, Rust's approach felt different. Rust doesn't have classes. It uses structs and traits. This forced me to use composition over inheritance and think differently about code structure.

Here's an example from my terrain generator:

pub struct NoiseFunctionParams {
  pub octaves: u32,
  pub height: f64,
  // ... 
}  

pub struct HeightParams {     
  pub noise: NoiseFunctionParams, // Composition!
  pub splines: Vec<Vec2>
}

Instead of inheriting from a base class, HeightParams contains a NoiseFunctionParams struct. This keeps the code flexible and avoids deep inheritance hierarchies.

Macros: Code That Writes Code

Rust's macros are like Ruby's metaprogramming but more structured and powerful. They help eliminate boilerplate while maintaining type safety.

Here's a macro I used to define blocks in my project:

macro_rules! add_block {
    ($block_id:expr, $is_solid:expr) => {
        Block {
            id: $block_id,
            is_solid: $is_solid,
        }
    };
}

pub static BLOCKS: [Block; 14] = [
    add_block!(BlockId::Air, false),
    add_block!(BlockId::Grass, true),
    // ...
];

Macros don't affect runtime performance. They are a zero-cost abstraction, a great feature of Rust.

Rust's Learning Curve: Worth the Effort?

Rust isn't the easiest language to pick up. The borrow checker takes time to understand, and coming from Ruby, its verbosity stands out. Ruby achieves more with fewer symbols. While Rust's explicitness helps with maintainability and reducing hidden behaviors, it also means writing more boilerplate.

One of the biggest disadvantages to me is compile times. They can be frustrating since Rust enforces strict checks, but this reduces runtime errors. There's even an XKCD comic about it.

From my experience, Rust has its trade-offs. Catching many errors at compile time reduces debugging effort, but the strict rules and verbosity make writing new code slower compared to Ruby. That said, Rust's language servers provide excellent refactoring support, which makes working with larger projects easier.

For quick prototyping and iteration, scripting languages such as Ruby are still the better choice. However, when stability, performance, and long-term maintainability matters, Rust seems to be the better pick.

Conclusion

Rust isn't just another language. It changes how you think about programming. It makes you more aware of memory, safety, and performance. The learning curve is steep, but if you stick with it, the rewards are worth it.

I hope you enjoyed this journey into Rust! If you're a Ruby developer who has also tried Rust, what challenges have you faced? I'd love to hear your thoughts!

Multiplayer in Rust using Renet and Bevy

Dani Bengl — Wed, 03 Jul 2024 15:24:33 +0000

Here at Renuo, we specialize in web technologies such as Ruby on Rails, React, Angular, and Spring. One of our core company values is continuous learning: we love exploring new technologies even beyond our usual scope of expertise.

Inspired by Michael’s Unity Powerday, I decided to delve into how multiplayer games operate. As a team, we held a competition to implement FPS (First-Person Shooter) games using C# boilerplate. Initially, the sheer amount of boilerplate required felt overwhelming. Beyond that, I wanted to understand client/server data synchronization at a lower level of abstraction.

My recent experiences with Rust and Bevy convinced me to write this blog article to share my newfound learnings of game development.

Why Choose Rust

Advantages

Rust is a statically typed, memory-safe, multi-paradigm programming language that matches the performance of C. Due to its safety, concurrency features, and modern syntax, it has gained popularity among developers in recent years.

Some notable software written in Rust includes:

Rapier3d: A performant physics engine often used with ThreeJS.
Ripgrep: A performant command line search tool.
Alacritty: A performant, minimalistic cross-platform terminal emulator.
Warp: A performant, modern terminal IDE.
Tauri: A performant and lightweight alternative to ElectronJS.
Amethyst: A performant tiling window manager for MacOS.
Condorium Blockchain: A performant and secure blockchain technology.

I mean, there is no such thing as a perfect programming language Rust is merely a statically type low-level multi-paradigm perfect programming language
YouTube interview by Programmers Are Also Human, Rust is a perfect programming language.

Picking a game engine

There are currently 5 games written in Rust. And 50 game engines.
Interview with a Senior Rust Developer - 2:52

There are too many game engines available for Rust. An excellent resource is Are We Game Yet. I also recommend this article by GeeksforGeeks, which makes picking the optimal engine easier.

The Difference Between Bevy and Other Engines

While big game engines like Godot, Unity, and Unreal Engine come with graphical editors, Bevy focuses on providing a simple yet powerful, multithreaded system to manage game state with minimal code.

Understanding ECS

The ECS (Entity Component System) is a software pattern that emphasizes a modular design. It is commonly utilized in game and game engine development. This approach separates the data and behaviour of game entities into components, making it easier to manage and organize complex systems.

Components of ECS

Entities: Unique identifiers of a group of components (A u32 wrapper in bevy).
Components: Modular data pieces that represent specific Entity attributes. (A struct that derives the Component macro in bevy)
System: Logic that operates on entities and their components. (A struct that derives the Resource macro in bevy)

Systems in Bevy

Systems in Bevy are functions that take various parameters such as queries, EventReaders, assets, and resources and apply logic to them.

One powerful feature of Bevy systems is the Query interface. It allows you to fetch specific data for entities in your project. For instance, if no entity is found, the single_mut() function will raise an error. Multiple queries are possible as long as entities do not overlap.

Below is an example where the MyPlayer component doesn't contain any data but is used to denote that the entity belongs to the client player.

pub fn update_player_movement_system(
    mut keyboard_events: EventReader<KeyboardInput>,
    mut query: Query<(&mut Transform, &MyPlayer)>,
) {
    let (mut transform, _) = query.single_mut();

    for event in keyboard_events.read() {
        let mut delta_position = Vec3::new(0.0, 0.0, 0.0);

        match event.key_code {
            KeyCode::KeyW => delta_position.z += 0.1,
            KeyCode::KeyS => delta_position.z -= 0.1,
            KeyCode::KeyA => delta_position.x -= 0.1,
            KeyCode::KeyD => delta_position.x += 0.1,
            _ => {}
        }

        let new_position = transform.translation + delta_position;
        transform.translation = new_position;
    }
}

The example above has a flaw: the player position update has a fixed step. Instead of using a fixed-step update, consider using the time passed since the last step. This will ensure a consistent movement speed regardless of the frame rate.

Picking Networking Libraries

We need to decide on networking libraries after choosing Bevy as our game engine. Here are a few options:

Matchbox
Naia
Renet
Bootleg_networking
Spicy_networking

I chose Renet because of its popularity and my good experiences with its boilerplate. Additionally, I included Serde for efficient binary message encoding.

Sketching the scene

Before coding, let's sketch a simple scene:

Camera: Renders the scene.
Plane: Represents the floor.
Green Cube: Represents the player.
Red Cubes: Represent other players.

Attributes to synchronize:

Position: Vec3

Input method:

Keyboard (WASD): Used to translate the player.

Handling Player inputs

There are three main ways to handle player inputs:

Client-side: The client handles inputs, moves the player, and sends the position to the server.
Server-side: The client sends input data to the server, and the server responds with the position.
Hybrid: The client handles inputs and shares them with the server, which then responds with position synchronization.

The client-side approach can reduce latency, but is less secure. The server-side approach is more secure but adds server load. The hybrid approach offers a balance, but is more complex.

Planning

Client

Type	Name	Description
Component	PlayerEntity(ClientId)	Represents an enemy player entity.
Component	MyPlayer	Marks the current player entity.
Event	PlayerSpawnEvent(ClientId)	Emitted when a player joins. Adds a player object to the scene.
Event	PlayerDespawnEvent(ClientId)	Emitted when a player leaves. Removes a player object from the scene.
Event	PlayerMoveEvent(ClientId, Vec3)	Emitted by the player controller when a player moves.
Event	LobbySyncEvent(HashMap)	Emitted when the client receives sync messages from the server. Updates other player positions using their ID and position.
System	send_message_system	Shares MyPlayer position data with the server.
System	receive_message_system	Processes messages received from the server.
System	update_player_movement_system	Updates player position from keyboard input.
System	setup_system	Sets up the scene with a camera, a ground plane, and a mesh for the current player.
System	handle_player_spawn_event_system	Adds enemy players to the scene once they join in.
System	handle_lobby_sync_event_system	Updates enemy player positions and potentially spawns missed players into the scene.

Server

Type	Name	Description
Resource	PlayerLobby(HashMap)	Holds attributes of all players currently in the game. Used to synchronize these attributes with the clients.
System	send_message_system	Broadcasts player positions to keep enemy player positions in clients up-to-date.
System	receive_message_system	Updates player lobby position based on messages received from the RenetClient.
System	handle_events_system	Handles events such as ClientConnected and ClientDisconnected from the Bevy Renet plugin.

Deciding on a project structure

I separated the ECS components into specific modules to structure the Bevy project and used two entry points: one for the client and one for the server. Shared code, such as structures for Client-Server communication, can be placed in a global lib module.

src
├── client
│   ├── components.rs
│   ├── events.rs
│   ├── main.rs
│   ├── resources.rs
│   └── systems.rs
├── lib.rs
└── server
    ├── main.rs
    ├── resources.rs
    └── systems.rs

Defining various entry points is as simple as adding this to the Cargo.toml file:

[[bin]]
name = "server"
path = "src/server/main.rs"

[[bin]]
name = "client"
path = "src/client/main.rs"

Afterwards, the binaries can be run with the --bin argument:

cargo run --bin server
cargo run --bin client

Setting up Boilerplate

To integrate bevy_renet into the bevy project, I followed the Bevy Renet documentation. In my setup, I used these two default channels:

Unreliable: Used for sending and receiving messages for player attribute synchronization. (We don't care about every state change, we can pick the last one)
ReliableOrdered: Used for sending and receiving messages for player actions such as joining and leaving.

Synchronising player positions

Here's an example of sending player attributes from the client to the server:

pub fn send_message_system(mut client: ResMut<RenetClient>, query: Query<(&MyPlayer, &Transform)>) {
    let (_, transform) = query.single();
    let player_sync = PlayerAttributes {
        position: transform.translation.into(),
    };
    let message = bincode::serialize(&player_sync).unwrap();
    client.send_message(DefaultChannel::Unreliable, message);
}

Handling messages from the client on the server:

pub fn receive_message_system(mut server: ResMut<RenetServer>, mut player_lobby: ResMut<PlayerLobby>) {
    for client_id in server.clients_id() {
        let message = server.receive_message(client_id, DefaultChannel::Unreliable);
        if let Some(message) = message {
            let player: PlayerAttributes = bincode::deserialize(&message).unwrap();
            player_lobby.0.insert(client_id, player);
        }
    }
}

Sending attributes of all players back to the client:

pub fn send_message_system(mut server: ResMut<RenetServer>, player_lobby: Res<PlayerLobby>) {
    let chanel = DefaultChannel::Unreliable;
    let lobby = player_lobby.0.clone();
    let event = multiplayer_demo::ServerMessage::LobbySync(lobby);
    let message = bincode::serialize(&event).unwrap();
    print_lobby(&player_lobby);
    server.broadcast_message(chanel, message);
}

Synchronizing the client scene with the player attributes from the server:

pub fn handle_lobby_sync_event_system(
    mut spawn_events: EventWriter<PlayerSpawnEvent>,
    mut sync_events: EventReader<LobbySyncEvent>,
    mut query: Query<(&PlayerEntity, &mut Transform)>,
    my_clinet_id: Res<MyClientId>,
) {
    let event_option = sync_events.read().last();
    if event_option.is_none() {
        return;
    }
    let event = event_option.unwrap();

    for (client_id, player_sync) in event.0.iter() {
        if *client_id == my_clinet_id.0 {
            continue;
        }

        let mut found = false;
        for (player_entity, mut transform) in query.iter_mut() {
            if *client_id == player_entity.0 {
                let new_position = player_sync.position;
                transform.translation = new_position.into();
                found = true;
            }
        }

        if !found {
            info!("Spawning player {}: {:?}", client_id, player_sync.position);
            spawn_events.send(PlayerSpawnEvent(*client_id));
        }
    }
}

Conclusion

The multiplayer demo project demonstrates the intricate planning and attention to detail needed to synchronize player attributes between the client and server. This showcases the complexity of creating a seamless multiplayer experience at a lower level.

For more detailed code, visit the MIT-Licensed GitHub repository.

2 Simple Configurations to Supercharge your TMUX Setup!

Dani Bengl — Sun, 14 Apr 2024 11:22:48 +0000

Tmux is a terminal multiplexer. It is a tool for managing multiple shells inside a single terminal window. It is integrated into most modern terminal emulators like Iterm2 or Warp. In this blog article, I will show you two simple configurations that drastically improved my tmux experience.

Autoresizing panes

The main problem I had with tmux when starting out was that panes were not automatically resized as I was used from Warp:

Don't get confused by the remapped tmux prefix. The main thing to notice here is that I am using <PREFIX> + E to spread the panes out evenly.

What we now need is:

The command to resize the windows
The hook(s) for executing the command
Update the tmux configuration with the hook and the command.

Part1: Finding the command

According to the manual entry for tmux:

select-layout [-Enop] [-t target-pane] [layout-name]
                             (alias: selectl)
                 Choose a specific layout for a window.  If layout-name is not given, the last preset layout used (if any) is
                 reapplied.  -n and -p are equivalent to the next-layout and previous-layout commands.  -o applies the last
                 set layout if possible (undoes the most recent layout change).  -E spreads the current pane and any panes
                 next to it out evenly.

We can use the select-layout -E command to spread the panes evenly.

Part2: Finding the hooks

The first part is done. Now we need the hooks.

Unsurprisingly, this can also be found in the manual entry:

%window-pane-changed window-id pane-id
     The active pane in the window with ID window-id changed to the pane with ID pane-id.

...

window-resized          Run when a window is resized.  This may be after the client-resized hook is run.

Part3: Updating the configuration file

If you haven't moved the .tmux.conf to .config, you can find the default configuration file for MacOS at ~/.tmux.conf.

To execute the command on the resize and pane changed hooks, we can add these lines to the tmux configuration:

# .tmux.conf
...
set-hook -g window-pane-changed 'select-layout -E'
set-hook -g client-resized 'select-layout -E'
...

This is how the panes behave after adjusting the configuration:

According to the manual entry, we can also shorten the command to the following:

set-hook -g window-pane-changed 'selectl -E'
set-hook -g client-resized 'selectl -E'

Dimming Inactive Panes

Next to automatically resizing windows, we can also automatically dim panes that aren't active by using the following configuration:

set-hook -g pane-focus-out 'select-pane -P bg=colour233,fg=colour10'
set-hook -g pane-focus-in 'select-pane -P bg=default,fg=default'

Now, this is a much nicer alternative than the active border color. If you are wondering how I got rid of it, I used this configuration:

set -g pane-active-border-style "bg=#000000,fg=white"
set -g pane-border-style "bg=#000000,fg=white"

Remember that black and #000000 are not the same thing when configuring your terminal, as the color names are defined by your color scheme.

Conclusion

While tmux isn't as usable/powerful out of the box as the integrated tmux in Iterm or Warp, with some simple configuration, it can be significantly improved. The manual page for tmux is the go to source for looking up commands and events and will save a lot of time googling.

Tools and Sources

Screen recorder: CleanShotX
Keystroke recorder: KeyCastr
Terminal Emulator: Alacritty
Other configuration: My Dotfiles

Extending Hotwire beyond Ruby on Rails

Dani Bengl — Fri, 08 Mar 2024 19:30:00 +0000

This blog article is inspired by a Hotwire Turbo streams tutorial for Sinatra.

When you search for Hotwire tutorials on Google, you’ll find that most of the results are related to Ruby on Rails. Even the Hotwire guides predominantly use Ruby on Rails as an example for implementing Turbo Streams.

This does not really come as a surprise, as the framework has been created by the same company behind the Ruby on Rails framework.

However, it’s important to recognize that Hotwire is not exclusively a Rails framework. In this blog article, I aim to convince you that Hotwire can be used beyond the Rails context, especially Turbo, its core feature.

Goals

In this blog article, I will explain:

Setting up a BunJS Application
Implementing client and server-side Web Sockets
Using turbo streams to update the UI
Creating a stimulus controller attached to the DOM

Step 1: Set up a BunJS Application

Initially, I considered using Java Spring for this blog, but I encountered challenges with Web Sockets. Instead, I opted for a much simpler TypeScript application.

Let’s start by initializing a new BunJS application:

mkdir bunjs-turbo-demo
cd bunjs-turbo-demo
bun init

Now, let’s run the application:

bun run index.ts
Hello via Bun!

Step 2: Implement a Simple Web Socket / HTTP Server with BunJS

Web Sockets serve as the backbone for real-time communication in our project. In this step, we’ll create a basic Web socket HTTP server using Bun. Web Sockets are essential for enabling bidirectional communication between clients (such as web browsers) and the server.

The Multiple Publisher - Multiple Subscriber Pattern

Our approach involves implementing the multiple publisher - multiple subscriber pattern. Here’s how it works:

Client Interaction:
- Clients (users' web browsers) initiate actions, such as sending chat messages or requesting updates.
- These interactions trigger Web Socket connections to the server.
Server Processing:
- The server receives messages from multiple clients.
- It processes these messages and prepares appropriate responses.
Broadcasting Updates:
- When a client sends a message (e.g., a new chat message), the server broadcasts it to all connected clients.
- This ensures that everyone receives the latest updates in real time.
Seamless Communication:
- Web Sockets allow seamless, low-latency communication.
- Clients can instantly receive updates without the need for manual page refreshes.

Here is a simple sequence diagram showing the core idea of this project:

Implement the server

For brevity, I’ve omitted the code for view helpers such as layoutHTML and chatRoomHTML. These helpers handle rendering HTML components and chat room layouts. While important, their details won’t significantly impact the core concepts discussed in this blog.

const topic = "chatroom";

Bun.serve({
  port: 8080,
  fetch(req, server) {
    const url = new URL(req.url)

    if (url.pathname === "/") return new Response(layoutHTML("Chatroom", chatRoomHTML()), {
      headers: {
        "Content-Type": "text/html",
      }
    })

    if (url.pathname === "/subscribe") {
        if (server.upgrade(req)) { return }
        return new Response("Couldn't upgrade to a WebSocket connection")
    }

    return new Response("404!");
  },
  websocket: {
    open(ws) {
      console.log("Websocket opened")
      ws.subscribe(topic)
      ws.publishText(topic, messageHTML("Someone joined the chat"))
    },
    message(ws, message) {
      console.log("Websocket received: ", message)
      ws.publishText(topic, messageHTML(`Anonymous: ${message}`))
    },
    close(ws) {
      console.log("Websocket closed")
      ws.publishText(topic, messageHTML("Someone left the chat"))
    },
    publishToSelf: true
  }
})

Implement the client

The application is incomplete without the client, which connects to the Web Socket server. Following the Web Socket server connection documentation, connecting to the backend is straightforward:

const client = new WebSocket("ws://localhost:8080/subscribe")
const form = document.getElementById("chat-form")
const chatFeed = document.getElementById("chat-feed")

client.addEventListener("message", (event) => {
  chatFeed.innerHTML += event.data
})

form.addEventListener("submit", (event) => {
  event.preventDefault()
  const formData = new FormData(form)
  const message = formData.get("message")
  client.send(message)
  form.reset()
})

Don't forget to add the route for the JavaScript file to the backend and include it inside your view using a module script tag. Also, make sure to implement the backend response.

The problem

As you can see here, every change in UI needs to be manually implemented. At the moment, we are listening to a single event and updating one single element. When the application grows in complexity, the JavaScript code grows, too. What if I told you that we can "almost" completely eliminate the client code by introducing Turbo streams?

Step 3: Implement Turbo streams

Turbo is a vital part of the Hotwire Framework. It enables you to dramatically reduce the amount of custom JavaScript you need to write.

The most relevant feature for this application are the turbo streams. They enable us to deliver page changes in the form of HTML over the wire.

Importing Turbo is as simple as including this snippet of code inside our layout file:

<script type="module">
    import hotwiredTurbo from 'https://cdn.jsdelivr.net/npm/@hotwired/turbo@8.0.3/+esm'
</script>

In order to use Web Sockets for Turbo streams in the frontend, we can use the following snippet from the stream documentation:

<turbo-stream-source src="ws://localhost:8080/subscribe" />

In order to update the UI when a message is sent, we broadcast the following HTML through Web Sockets:

<turbo-stream action="append" target="chat-feed">
    <template>
        <p class="notice">
           Anonymous: Hello World!
        </p>
    </template>
</turbo-stream>

This method of HTML updates stands out for its transparency and simplicity. Firstly, we select an element with the #chat-feed selector and then append to it the contents of the broadcasted template. In this case, a paragraph containing the user message. This also eliminates almost all the client-side JavaScript needed for page update.

Step 4: Implement Form Controller

Before introducing turbo, we added a simple event listener to reset the Form after the data has been sent to the server. We now need to bring the functionality back, but without reusing the old code. We could use a turbo-stream to reset the form or even a turbo-frame, but rather than using that, I decided to use another library of the Hotwire framework, namely Stimulus:

Stimulus is a JavaScript framework with modest ambitions. It doesn’t seek to take over your entire front-end—in fact, it’s not concerned with rendering HTML at all. Instead, it’s designed to augment your HTML with just enough behavior to make it shine.

https://stimulus.hotwired.dev/

This is a simple code snippet for the Form Stimulus controller:

import { Application, Controller } from "https://cdn.jsdelivr.net/npm/stimulus@3.2.2/+esm"

class FormController extends Controller {
  clear() {
    this.element.reset()
  }
}

const application = Application.start();
application.register("form", FormController);

This is what the form HTML looks like, with data attributes used to attach the controller to the DOM and hook the events up to the corresponding controller methods:

  <form id="chat-form" action="/submit" method="post" data-controller="form" data-action="turbo:submit-end->form#clear">
    <label for="message-input">Message:</label>
    <input name="message" data-form-target="input" required >
    <input type="hidden" name="clientId" value="${clientId}">
    <input type="submit" value="Send">
  </form>

The event that works best for form submission in that case is turbo:submit-end. Following the documentation of Stimulus descriptors, we can call the #clear() method after the form submission event. We are not using the submit event because this would clear the form prematurely.

Conclusion

Hotwire is a JavaScript framework that helps us make applications more interactive while keeping the JavaScript code to a minimum. While the framework has been created by the authors of Ruby on Rails, the framework itself is backend agnostic.
Turbo streams enable us to update client user interfaces asynchronously without the need for any (in some cases, just very little) frontend code.
Stimulus enables us to add simple JavaScript behavior to our HTML with the use of Stimulus Controllers and data-attributes.

Where can I find the source?

You can find the complete chatting application with additional features such as:

Client identification via Query Parameters
Random username generation
Real-time user list

The GitHub Repository for this project can be found here: https://github.com/CuddlyBunion341/bunjs-turbo-demo