Why Roc Is Moving Away From Rust to Zig

Today’s Issue: Cooperative Multitasking in Rust, Updating a Large Codebase to Rust 2024, and Another Round of Rust for Linux Drama.

Ferris the crab mascot - Image courtesy of tweedegolf

Hello Rustaceans! 🦀

In this issue, we’ll discuss why Roc is moving away from Rust with a scratch-rewrite in Zig, challenge you with a palindrome permutation problem, spotlight an amazing Rust project, and share some incredible links of the week.

Here’s issue 53 for you!

THE MAIN THING

Why Roc Is Moving Away From Rust to Zig

Richard Feldman, the Creator of the Roc programming language recently announced that they are scratch-writing their compiler from Rust to Zig. This rewrite is expected to be the major 0.1.0 release for Roc.

In his announcement, he reflected on the nature of the compiler rewrite, the advantages of doing so, and the process of transitioning from Rust to Zig. In Roc’s case, the team chose Zig due to its various advantages, such as faster compile times, specific language features, and its fit for the project's long-term goals.

Reasons for the Rewrite
A key reason for this decision was that the Roc team had already planned to rewrite most of the compiler components due to the complexity and limitations of the existing codebase.

Components like the parser, type inference, documentation generation, and LLVM code generation were in need of substantial changes and improvements. Since the team was planning to rewrite nearly every part of the code, they concluded that switching to a new language, Zig, would be a more practical long-term solution than staying with Rust.

Why Zig Over Rust?
Richard expressed several reasons for choosing Zig instead of Rust for the scratch-rewrite:

• Rust's slow compile times is a major pain point, slowing down productivity. Zig offers much faster compile times, which will improve developer efficiency and feedback loops.

• While Rust’s memory safety features are advantageous in many contexts, they are not necessary for the Roc compiler. Zig's approach to memory management, which uses allocators, aligns better with the Roc's needs.

• Zig has features that are better suited for the Roc compiler, such as improved struct-of-arrays programming, better handling of LLVM bitcode, and easier static linking of Linux binaries.

• Richard noted that Rust ecosystem's large size was initially appealing, but after filtering out unnecessary dependencies, the Zig ecosystem provided the tools and libraries that the team required.

While Roc’s team recognizes that the rewrite is an opportunity to address shortcomings from the previous implementation, their plan is to "fuzz early," document the process more thoroughly, and avoid using shortcuts (like panic functions) that caused problems in the past.

The intent of the scratch-rewrite is to maintain a balance between performance and maintainability, where initial clarity and ease of debugging will take precedence. If you want to catch up on the whole gist check out Rewrite. We can’t wait but wish Roc all the best.

RUST CHALLENGE

In the previous issue, we challenged you to group and count consecutive elements in an array. A big thanks to everyone who took on the challenge! You can find our solution on Rust Playground.

Let's move on to this weeks challenge.

Palindrome Permutation Check

Given a string s, determine if a permutation of the string can form a palindrome after:

1. Ignoring all non-alphanumeric characters.

2. Treating uppercase and lowercase letters as identical.

Return true if the criteria are satisfied, otherwise false.

Example:

assert!(can_form_palindrome("Tact Coa"));
assert!(!can_form_palindrome("hello"));
assert!(can_form_palindrome("A man a plan a canal Panama"));

Test your solution on Rust Playground. Once completed, please share your code on Twitter, or as a reply to this email.

PROJECT SPOTLIGHT 💡

Rustix - Safe Syscalls with Rust Precision

Systems programming often requires dealing with low-level APIs, Rustix makes life a whole lot easier when working with POSIX-like syscalls, Unix-like systems, and even Winsock on Windows.

Rustix provides memory-safe, I/O-safe bindings for these system-level APIs, enabling you to work at a low level without compromising on Rust’s core safety guarantees.

If you’ve ever worked with raw pointers, manually managing file descriptors, or dealt with the pain of using unsafe blocks to interface with syscalls in C or C++, Rustix is your ticket to safer, more ergonomic code. It uses types like OwnedFd and AsFd for managing file descriptors, which significantly reduces the chances of memory-related errors.

Here are a few reasons why you’ll want to take Rustix for a spin:

1. No More Unsafe - Rustix avoids raw pointers and unsafe code as much as possible, instead relying on Rust’s own memory management system to ensure safe I/O operations.

2. Multiple Backends - Rustix gives you the flexibility of using different backends based on your platform. It provides linux_raw for access to raw Linux system calls, and libc for Unix-family platforms.

3. Fine-Grained Control - Rustix provides efficient and flexible handling of system-level operations, from network operations (including Winsock support) to memory maps, file system operations, and even event polling.

4. Extensible API - Whether you’re working with process management (rustix::process), time operations (rustix::time), or terminal I/O (rustix::termios), Rustix’s modular design makes it easy to pick and choose the functionality you need, with support for various cargo features to customize your builds.

Rustix also gives you the benefits of high-level abstractions with zero cost. The abstractions are efficient and compile down to tight, inlined code, so you don’t sacrifice performance.

This project is open-source on GitHub, so go ahead—fork it and contribute your awesomeness.

AWESOME LINKS OF THE WEEK 🔗

1. Josh Haberman wrote about No-Panic Rust: A Nice Technique for Systems Programming.

2. Pavel Yosifovich authored an insightful tutorial on Writing a Simple Driver in Rust.

3. Amos aka fasterthanlime wrote an insightful article on The case for sans-io.

4. The debate over Rust in the Linux kernel has developers feeling 'oxidized' by proposed abstractions for DMA mapping, with some likening the mix of Rust and C to 'cancer' in the codebase.

5. Elric Neumann discussed about Cooperative multitasking in Rust.

6. Eric Seppanen shared his adventures updating a large codebase to Rust 2024 edition. Curious how to level up yours? This guide’s got you covered!

7. Evan Schwartz wrote an insightful article on Pinning Down "Future Is Not Send" Errors.

8. The talented team at Fyrox Games has released Fyrox Game Engine v0.36, marking the project's most significant update to date.

9. Octave Larose shared his experience integrating the MMTk garbage collection framework into Rust-based interpreters.

10. Oleksandr Prokhorenko wrote about Computed Properties in Rust and how to implement them effectively.

SUPPORT RUST BYTES👋

You're Rust Bytes biggest fans, and we love to see it. Here’s how you can help spread the word:

• ❤️ Recommend Rust Bytes to your friends.

• 🤳 Connect with us on our socials: X, Rustaceans Publication.

• 📨 Email us at rustaceanseditors@gmail.com with feedback or ideas.

• ☕️ Buy us a coffee to support our editors!

That's all for now, Rustaceans. “Don’t worry about looking good, worry about achieving your goals”.

John & Elley.