The State of Async Rust: Runtimes

The State of Async Rust: Runtimes

In the world of Rust programming, the use of Arc or Mutex can often indicate a design that hasn't fully embraced the ownership and borrowing principles that Rust emphasizes. These constructs, while useful in certain scenarios, introduce shared mutable state that can lead to issues down the line. It's crucial to take a step back and consider if the shared state is truly necessary or if there's an alternative design that can minimize or eliminate the need for it.

One factor that contributes to this issue is the Tokio runtime, which imposes a certain design on developers. With Tokio, the choice of using Arc or Mutex may feel like the only option, even if it goes against the principles of Rust. This lack of flexibility can be frustrating, as it limits the developer's ability to fully embrace the ownership model that Rust promotes.

On a separate note, GitHub Actions is a powerful tool for automating workflows, but it can also be a source of frustration if not used correctly. There are two approaches to building GitHub Actions workflows: programming with GitHub Actions or configuring with GitHub Actions.

The first approach involves writing extensive YAML files that become convoluted and difficult to understand. This approach often leads to vendor lock-in, as developers rely on marketplace tools to achieve their desired functionality. The workflows become bloated, reaching lengths of 500-1000 lines, and they are filled with unnecessary conditionals. It's a nightmare to maintain and makes the YAML unreadable.

The second approach, configuring with GitHub Actions, encourages developers to push the complexity of their workflows into scripts whenever possible. By asking themselves if a particular task can be accomplished through a script, developers can keep their workflows concise and manageable. This approach drastically reduces the size of the YAML file, often resulting in workflows of only 50-60 lines. Once set up, these workflows rarely need to be changed. Additionally, debugging becomes easier as developers can debug the script locally without the need for the tedious push-debug-commit loop.

Surprisingly, despite the advantages of the second approach, many developers still opt for the first approach. Even when presented with the benefits of a simpler, more maintainable workflow, a significant portion of teams continue to choose the convoluted path. It's a perplexing phenomenon that highlights the need for better education and awareness regarding the best practices for utilizing GitHub Actions.

Moreover, the lack of debugging tools provided by Microsoft for GitHub Actions is often seen as a drawback. However, when following the second approach, where workflows are primarily configured with scripts, this limitation becomes less problematic. By reducing the reliance on complex YAML files, developers can leverage their local debugging tools, minimizing the impact of this issue.

To navigate the complexities of async Rust and GitHub Actions effectively, here are three actionable pieces of advice:

1. Embrace Rust's ownership and borrowing principles: Whenever you find yourself reaching for an Arc or Mutex, pause and reconsider if shared mutable state is truly necessary. Explore alternative designs that minimize or eliminate the need for such constructs. By fully embracing Rust's ownership model, you can create more robust and efficient code.

2. Opt for configuring with GitHub Actions: Instead of writing convoluted YAML files, focus on pushing the complexity into scripts whenever possible. Keep your workflows concise and manageable, reducing the chances of vendor lock-in and making debugging easier. By following this approach, you'll have more control over your workflows and avoid unnecessary complexities.

3. Educate your team on best practices: Share the benefits and drawbacks of both approaches to GitHub Actions workflows with your team. Encourage them to adopt the configuring approach and explain the advantages it brings, such as reduced complexity, easier debugging, and lower chances of vendor lock-in. By fostering a culture of informed decision-making, you can ensure that your team follows the most effective practices.

In conclusion, the state of async Rust and GitHub Actions workflows presents both challenges and opportunities. By embracing Rust's principles and carefully considering the design choices, developers can create more robust and efficient code. Additionally, by opting for the configuring approach in GitHub Actions workflows and educating teams on best practices, developers can avoid unnecessary complexities and fully leverage the power of automation.