A Web Programmer's Impressions of Rust

I usually write PHP or TypeScript, but I tried Rust out of curiosity, so I'm leaving my impressions here.

The Official Toolchain is Comprehensive

Since I often write TypeScript, I thought it was great that I didn't have to think about things like transpiling or bundling. Both the formatter and linter are included as soon as you install rustup.

rustlings is Great

rustlings was an excellent learning environment. Even as a beginner, I didn't run into any setup issues, and it was fun, like a game. Since it takes a "broad but shallow" approach, it's easy to get an overall picture and visualize which areas to delve deeper into once you're finished.

Because the type system is unique and I haven't done much systems programming until now, I felt I wanted to deepen my understanding of things like:

• Knowledge of the standard library
  • Traits
  • Implementation of design patterns (mainly related to concurrent programming)
• Asynchronous processing
• Macros

I found out later after being told that a Japanese version apparently exists.
I didn't know about it, so I solved the English version while using Google Translate.
sotanengel/rustlings-jp: Japanese translation of Rust exercises (Rustlings).

Result is Excellent

Rust is often associated with memory safety guaranteed by static type checks, but I found the Result type to be incredibly convenient.

In particular, the question mark operator is very handy.

fn()?;

This is because, when writing TypeScript, I often struggle with how to design error handling. Common patterns include:

• Throwing exceptions
• Returning the result as a return value

The former is often used when you want to aggregate errors and process them in one place. This applies when it's okay for the process to crash, or when processing with error-handling middleware in web applications. It's slightly outside the context of typical error handling, but sometimes it's used in unique ways by taking advantage of its non-local exit property.
Why throwing a Promise is a genius design #JavaScript - Qiita

The latter is for other cases... it depends, but for example, in HTTP clients, it's often designed to return a response object without throwing an exception to represent error responses. Though some libraries throw exceptions if an error status code is returned. Things called Either or Result also fall into this category.

When using the "return the result as a return value" pattern in TypeScript, it can feel a bit redundant when I want to write "if it's an error, do XX; otherwise, do OO."
For example, a schema validation looks like this:

  const v = someSchema.safeParse(obj);
  if (!v.success) {
    // Validation failed!
    return;
  }
  
  // Validation OK!
  return;

Using exceptions allows for more concise code, but it has its own problems, such as errors not appearing in the function signature.

  const v = someSchema.parse(obj);
  // Validation OK!
  // (An exception is thrown if it fails)
  return;

In this regard, Rust's Result type comes with excellent syntactic sugar.

  let r = some_fn()?;

  // If some_fn returns an error, it is returned immediately. The following lines are not executed.
  process_result(r);
  return Ok();

In addition to being concise, it has the advantage of errors appearing in the signature.
It's also easy to write logic for transforming errors or success values because of the wealth of useful methods like map_err.

Impressions

I had a strong association with memory safety, but there were surprisingly many other points I liked, and it felt like I could reap the benefits even with casual use.
I'm not at the point where I'd immediately switch my web development language to Rust, but I'd like to actively use it for things like writing CLI tools.