Forem: Federico Terzi

The single, most important trick to build robust applications

Federico Terzi — Wed, 21 Sep 2022 19:53:31 +0000

I'm Federico, a Software Engineer specialized in Frontend Development and System Programming. You can find out more about my work on Twitter, YouTube and GitHub.

This post originally appeared on my personal blog.

In the last decade, many functional programming concepts have been making their way into modern, non-functional languages. Instead of going all-in, developers can choose to gradually adopt some of the paradigms in their applications, enjoying the best of both worlds.

In this article, we are going to discuss a functional programming technique that can greatly improve the reliability of your front-end applications: making invalid states unrepresentable. Although these concepts can be applied to most frameworks and languages, we are going to focus on React applications written in TypeScript.

Our example

To start our discussion, we are going to focus on a simple login form as an example (you can find the complete code in this Codesandbox).
In a nutshell, the example is composed of:

A LoginBox component, which contains the input fields and invokes a callback when the user clicks on Login
A login function, which simulates a network call to a login endpoint. If successful, this function returns a token.
The App component, which keeps the application state and displays the appropriate messages/components.

Here's the complete code:

import { useState } from "react";

const LoginBox = ({
  onLogin
}: {
  onLogin: (user: string, pass: string) => void;
}) => {
  const [user, setUser] = useState("");
  const [pass, setPass] = useState("");

  return (
    <div>
      <p>Insert login details (use 'test' as password for correct logins)</p>
      <label htmlFor="user">User</label>
      <input
        type="text"
        value={user}
        onChange={(e) => setUser(e.target.value)}
      />
      <label htmlFor="pass">Password</label>
      <input
        name="pass"
        type="password"
        value={pass}
        onChange={(e) => setPass(e.target.value)}
      />
      <button onClick={() => onLogin(user, pass)}>Login</button>
    </div>
  );
};

// Simulate a login request
function login(user: string, pass: string): Promise<string> {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (pass === "test") {
        // Return a fake user token
        resolve("c6041ffc-5e13-4f6d-bb33-bf9d3ae20262");
      } else {
        reject(new Error("invalid password"));
      }
    }, 1000);
  });
}

export default function App() {
  const [loading, setLoading] = useState(false);
  const [userToken, setUserToken] = useState<string | undefined>(undefined);
  const [error, setError] = useState<unknown | undefined>(undefined);

  const handleLogin = async (user: string, pass: string) => {
    setLoading(true);

    // If we don't reset them here, we might have inconsistencies
    // after multiple logins
    setError(undefined);
    setUserToken(undefined);

    try {
      const newUserToken = await login(user, pass);

      setUserToken(newUserToken);
    } catch (error) {
      setError(error);
    }

    // We need to explicitly tell react that we are not loading anymore
    setLoading(false);
  };

  const handleLogout = () => {
    setUserToken(undefined);
  };

  return (
    <div className="App">
      <h1>Login Example</h1>

      {loading && <p>Loading...</p>}
      {error && <p>An error occurred: {String(error)}</p>}
      {!userToken ? (
        <LoginBox onLogin={handleLogin} />
      ) : (
        <>
          <p>You're logged in! Your user token is {userToken}</p>
          <button onClick={handleLogout}>Logout</button>
        </>
      )}
    </div>
  );
}

The problem

The example proposed above works as expected, but it's not very maintainable. The main problem lies in the fact that the different app-state fields (loading, error, userToken) are stored and updated independently.

Suppose at some point, a coworker not particularly familiar with this area of the codebase changes the handleLogin logic to fit some new requirements. As part of the process, they mistakenly forget to reset the error state with setError(undefined):

  const handleLogin = async (user: string, pass: string) => {
    setLoading(true);

    // The coworker deletes the following line
    // setError(undefined);  <- this one gets deleted
    setUserToken(undefined);

    try {
      const newUserToken = await login(user, pass);

      setUserToken(newUserToken);
    } catch (error) {
      setError(error);
    }

    // We need to explicitly tell react that we are not loading anymore
    setLoading(false);
  };

The coworker now attempts to log in and it works as expected:

The happy coworker then proceeds to create PR and, with a non-zero probability, the PR gets approved and goes into staging/production.

Happy ending, right? Not exactly. The application can now enter an inconsistent state when a user gets the first login wrong and the second one correct:

As you can see, the error message is still being shown after a successful login attempt.
This is happening because the setError(undefined) call has been removed, and as a result, the error message is not being reset when performing a new login attempt.

It might be easy to blame the coworker for such an oversight, but actually, the problem lies in the way the application state was originally structured. By having the error, loading and userToken states being updated independently, we made it easier to get into an inconsistent state.

Remember, the best systems are the ones that make it harder to do wrong things. In the following sections, we're going to analyze a design that could have prevented such mistakes.

In the previous example, I chose an hypothetical coworker as the person doing the mistake. I'm definitely not implying that only coworkers make mistakes, everyone does. I do plenty of mistakes on a daily basis :)

A better approach (but still not optimal)

I hear some of you screaming: "You should have used useReducer/Redux/Zustand/{random pokemon name} instead of those multiple useState!"

Indeed, in real-world scenarios, you would have likely used a more structured approach to handle the app state, but that doesn't necessarily solve the problem of invalid states.

For example, let's refactor the App code to use React's useReducer instead of multiple useState:

// This is the app state
type State = {
  loading: boolean;
  error?: unknown;
  userToken?: string;
};

const initialState: State = {
  loading: false
};

// The various actions we can use to update that state
type PendingAction = {
  type: "pending";
};

type SuccessAction = {
  type: "success";
  userToken: string;
};

type FailureAction = {
  type: "failure";
  error: unknown;
};

type LogoutAction = {
  type: "logout";
};

type Action = PendingAction | SuccessAction | FailureAction | LogoutAction;

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case "pending":
      return {
        loading: true
      };
    case "success":
      return {
        loading: false,
        userToken: action.userToken
      };
    case "failure":
      return {
        loading: false,
        error: action.error
      };
    case "logout":
      return initialState;
  }
}

export default function App() {
  const [state, dispatch] = useReducer(reducer, initialState);

  const handleLogin = async (user: string, pass: string) => {
    dispatch({ type: "pending" });

    try {
      const newUserToken = await login(user, pass);

      dispatch({ type: "success", userToken: newUserToken });
    } catch (error) {
      dispatch({ type: "failure", error });
    }
  };

  const handleLogout = () => {
    dispatch({ type: "logout" });
  };

  return (
    <div className="App">
      <h1>Login Example</h1>

      {state.loading && <p>Loading...</p>}
      {state.error && <p>An error occurred: {String(state.error)}</p>}
      {!state.userToken ? (
        <LoginBox onLogin={handleLogin} />
      ) : (
        <>
          <p>You're logged in! Your user token is {state.userToken}</p>
          <button onClick={handleLogout}>Logout</button>
        </>
      )}
    </div>
  );
}

This version improves our example on multiple fronts:

The handlers (handleLogin and handleLogout) don't need to know about the internal state representation anymore, but can simply dispatch actions in a declarative way.
It's harder to forget updating a slice of the state, as they are handled in a central place (the reducer function) instead of being scattered around handlers.

That said, despite making it harder to make the state inconsistent, it's still possible to do so.

Let's say that our product manager requests to implement a "failed attempts" counter. In a rush, we modify the failure case of the reducer to be based on the previous state:

    case "failure":
      return {
        ...state,
        error: action.error,
        failedAttempts: state.failedAttempts + 1,
      };

As a result, the "Loading..." label is still shown after a failed login attempt:

Of course, this is another silly oversight that would have been easy to spot. We forgot to set loading: false, and instead took the previous state value (true) using the spread operator ...state. Unfortunately, in real-world systems it's easy to make such mistakes when the state is made of many fields, and such oversights might not be as easy to spot.

Luckily, we can take this solution a step further. What if we let the compiler spot such mistakes? The answer is making invalid states unrepresentable.

Making invalid states unrepresentable

Let's start from the previous state representation:

type State = {
  loading: boolean;
  error?: unknown;
  userToken?: string;
};

The first question we should be asking ourselves is: what are the possible states of this system? There is no single best answer, but a possible representation could be:

Idle
Login pending
Login success
Login failure

If the idle state doesn't make sense to you, keep in mind we are trying to model all the possible states of this system. Idle represents the state of the system before the user makes a login attempt.

Then, we can think about which fields and values those states can have:

Idle (loading = false)
Login pending (loading = true)
Login success (loading = false, userToken = string)
Login failure (loading = false, error = Error/unknown/whatever is relevant)

At this point, we can translate these states into code using Typescript's Discriminated unions (also known as Algebraic Data Types):

type State =
  | {
      type: "idle";
      loading: false;
    }
  | {
      type: "pending";
      loading: true;
    }
  | {
      type: "success";
      loading: false;
      userToken: string;
    }
  | {
      type: "failure";
      loading: false;
      error: unknown;
    };

Note how for each state, we are explicitly specifying which fields are present and, for some of them, even their value. Discriminated unions give us two superpowers:

We don't need to add optional fields everywhere, nor do we need to check for undefined values. If a state has type = "success" then Typescript guarantees that the userToken field will be available. In the same way, we won't be able to access the userToken if the state is failure

// This compiles correctly
if (state.type === "success") {
  console.log(state.userToken)
}

// This doesn't (and it's good!)
if (state.type === "failure") {
  console.log(state.userToken)
}

We won't be able to set inconsistent states in the reducer

Updating our previous example with the new approach, we get:

type State =
  | {
      type: "idle";
      loading: false;
    }
  | {
      type: "pending";
      loading: true;
    }
  | {
      type: "success";
      loading: false;
      userToken: string;
    }
  | {
      type: "failure";
      loading: false;
      error: unknown;
    };

const initialState: State = {
  type: "idle",
  loading: false
};

type PendingAction = {
  type: "pending";
};

type SuccessAction = {
  type: "success";
  userToken: string;
};

type FailureAction = {
  type: "failure";
  error: unknown;
};

type LogoutAction = {
  type: "logout";
};

type Action = PendingAction | SuccessAction | FailureAction | LogoutAction;

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case "pending":
      return {
        type: "pending",
        loading: true
      };
    case "success":
      return {
        type: "success",
        loading: false,
        userToken: action.userToken
      };
    case "failure":
      return {
        ...state,
        type: "failure",
        loading: false,
        error: action.error
      };
    case "logout":
      return initialState;
  }
}

export default function App() {
  const [state, dispatch] = useReducer(reducer, initialState);

  const handleLogin = async (user: string, pass: string) => {
    dispatch({ type: "pending" });

    try {
      const newUserToken = await login(user, pass);

      dispatch({ type: "success", userToken: newUserToken });
    } catch (error) {
      dispatch({ type: "failure", error });
    }
  };

  const handleLogout = () => {
    dispatch({ type: "logout" });
  };

  return (
    <div className="App">
      <h1>Login Example</h1>

      {state.loading && <p>Loading...</p>}
      {state.type === "failure" && (
        <p>An error occurred: {String(state.error)}</p>
      )}
      {state.type !== "success" ? (
        <LoginBox onLogin={handleLogin} />
      ) : (
        <>
          <p>You're logged in! Your user token is {state.userToken}</p>
          <button onClick={handleLogout}>Logout</button>
        </>
      )}
    </div>
  );
}

At this point, Typescript will make sure that the state is always in a consistent state. For example, the previous mistake (forgetting loading: false in the failure case due to the spread operator) won't compile:

We made invalid states unrepresentable 😎

Note: You might be wondering why we added the loading field to all states. The reason is that I thought it would make the example easier to understand. But in this simple scenario, we could drop the loading field entirely and only show the loading message when the state is pending (state.type === 'pending').

Final thoughts

All right! We started from a problematic example and gradually improved the way our state is represented, making the app more robust along the way.

It's important to consider these techniques as an additional tool you have at your disposal rather than absolute truths. There might be cases where these techniques are impractical for several reasons. As always, use the right tool for the job!

If you're interested, you can find the complete code for our final solution in this Codesandbox.

Automatic Code-signing and Notarization for macOS apps using GitHub Actions

Federico Terzi — Sun, 11 Sep 2022 15:14:17 +0000

I'm Federico, a Software Engineer specialized in Frontend Development and System Programming. You can find out more about my work on Twitter, YouTube and GitHub.

This post originally appeared on my personal blog.

After almost 3 years, we finally took the necessary steps to code-sign Espanso. This article covers the step I’ve taken to integrate the code-signing and notarization steps in our automatic CI flow. This process is built with GitHub Actions in mind, but you can easily port it to your CI provider of choice.

Prerequisites

Having a paid Apple Developer Program subscription. This costs about ~$99 per year depending on your country and is necessary to generate the required certificates.
Having a CI that builds your final App bundle. This bundle can be generated in a lot of different ways, just keep in mind we’ll need the final bundle.app inside the CI to perform the signing and notarization. This article won't cover the bundle generation, so please take care of that beforehand if you haven't already.

Generating the Certificate

If you have already generated a certificate for your app, feel free to skip this section

In order to sign the app, we need a valid certificate issued from Apple. You can issue one following these steps:

Navigate to the Apple Developer portal into the Certificates, Identifiers & Profiles section and select “Create a New Profile”
You’ll be asked to choose a certificate type, select “Developer ID Application” from the options and then continue

Selecting the right option from the “Create a New Certificate” section

For the “Developer ID Certificate Intermediary” choose G2 Sub-CA (Xcode 11.4.1 or later) and keep this webpage open, we’ll get back to it later

Then, we need to generate a Certificate Signing Request (CSR). We can do so by opening the “Keychain Access” app on macOS, selecting Certificate Assistant > Request a Certificate From a Certificate Authority...

You’ll be prompted for some information, make sure to specify the same email you used for your paid Apple Developer subscription, then check the Save to Disk option, and click Continue
This will create a CertificateSigningRequest.certSigningRequest file in your location of choice. Go back to the “Create a New Certificate” webpage we opened earlier and click on “Choose File”, selecting the certificate request file we just created. Finally, click “Continue”
On the Apple Developer portal, you should now see your new certificate. Download it and open it using the Keychain Access app on your mac. It should look like this:
Please note down the full name of the certificate (such as Developer ID Application: Your Name (K1234), as we will need it later)

This certificate is ready to be used locally, but we want to export it in a format that is usable inside an automated (and headless) CI environment. For this reason, we are going to use the same trick from this great article by Localazy, exporting the certificate file and then encoding it as base64.

Select both the certificate (Developer ID Application: …) and the private key (the item below), then right click and choose “Export 2 items…”
In the panel that opens up, select a target location for the certificate file and choose Personal Information Exchange (.p12) format.
You’ll be asked for a password, generate a strong one using your tool of choice and note it down, as we’ll need it in the upcoming steps
Open a terminal, cd into the directory in which you created the certificate file, and convert it into base64 using this command:
```
base64 Certificates > Certificates.base64
```
This command will create a new Certificates.base64 file with the certificate encoded as base64 string. Keep this file around, as we’ll need it when populating the GitHub Actions secrets.

Gathering the Notarization information

Before diving into the GitHub Actions setup, we need to gather some more information for the notarization step:

Generating an app-specific password

We need to generate an Apple’s app-specific password for the notarization step:

Navigate and sign in to appleid.apple.com using the same account as your paid Apple Developer subscription
On the Sign-in and Security page, select “App-Specific Passwords”
Then select “Generate App-Specific Password”, and give it a meaningful name, such as “Project CI Notarization”
Then, enter your account password and finally “Continue”
You should now see a generated password, please note it down as we’ll need it later.

Getting your Team ID

Head over to the membership page, logging in if necessary
Inside the page, you should see a Team ID field. Note it down, as we will need it later

Setting up the GitHub Actions pipeline

Now that we gathered all the necessary information, it’s time to set up the GitHub Actions steps that will code-sign and notarize our app.

Setting up the Secrets

Navigate to your GitHub project Settings > Security > Secrets > Actions. Here we’ll need to register several secrets for the process to work correctly, so let’s start:

PROD_MACOS_CERTIFICATE should contain the base64 of the certificate we generated earlier. In particular, you should paste the content of the Certificates.base64 file here
PROD_MACOS_CERTIFICATE_NAME should contain the full certificate name, such as Developer ID Application: Your Name (K1234567)
PROD_MACOS_CERTIFICATE_PWD should contain the password you choose when exporting the certificate from the Keychain Access app
PROD_MACOS_NOTARIZATION_APPLE_ID should contain your apple developer email, the same you use for the Apple Developer subscription
PROD_MACOS_NOTARIZATION_PWD should contain the app-specific password we generated earlier
PROD_MACOS_NOTARIZATION_TEAM_ID should contain the Team ID we got earlier from the membership page
PROD_MACOS_CI_KEYCHAIN_PWD should contain a strong, randomly generated password. Feel free to use your tool of choice for this.

If you did everything right, you should end up with these 7 secrets in your GitHub Actions:

Defining the Code-signing step

Now that we have all our secrets in place, we are ready to define the code-signing step. For the sake of these examples, we assume that the app bundle will be placed in the target/mac/Espanso.app path inside the CI environment. Make sure to replace it with the appropriate location of your app.

This is what the GitHub Actions step should look like in the end, with comments explaining the various sections:

- name: Codesign app bundle
  # Extract the secrets we defined earlier as environment variables
  env: 
    MACOS_CERTIFICATE: ${{ secrets.PROD_MACOS_CERTIFICATE }}
    MACOS_CERTIFICATE_PWD: ${{ secrets.PROD_MACOS_CERTIFICATE_PWD }}
    MACOS_CERTIFICATE_NAME: ${{ secrets.PROD_MACOS_CERTIFICATE_NAME }}
    MACOS_CI_KEYCHAIN_PWD: ${{ secrets.PROD_MACOS_CI_KEYCHAIN_PWD }}
  run: |
    # Turn our base64-encoded certificate back to a regular .p12 file

    echo $MACOS_CERTIFICATE | base64 --decode > certificate.p12

    # We need to create a new keychain, otherwise using the certificate will prompt
    # with a UI dialog asking for the certificate password, which we can't
    # use in a headless CI environment

    security create-keychain -p "$MACOS_CI_KEYCHAIN_PWD" build.keychain 
    security default-keychain -s build.keychain
    security unlock-keychain -p "$MACOS_CI_KEYCHAIN_PWD" build.keychain
    security import certificate.p12 -k build.keychain -P "$MACOS_CERTIFICATE_PWD" -T /usr/bin/codesign
    security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$MACOS_CI_KEYCHAIN_PWD" build.keychain

    # We finally codesign our app bundle, specifying the Hardened runtime option

    /usr/bin/codesign --force -s "$MACOS_CERTIFICATE_NAME" --options runtime target/mac/Espanso.app -v

A note before proceeding further:

Specifying the --options runtime flag for the codesign command enables the Hardened Runtime for our app. This is necessary to pass the following notarization step (otherwise it fails when notarizing), but this might interfere with your app, as it disables JIT and other dynamic features. If you need them, you’ll need to specify the exceptions in your app’s entitlement file, as explained in the hardened runtime documentation.

Defining the Notarization step

After the code-signing step, our app is ready to be Notarized, which is necessary to prevent macOS from showing a scary warning to our users when opening the app.

The GitHub Action step should look like the following. This again assumes that the app bundle is located in the target/mac/Espanso.app path, so adapt it accordingly:

- name: "Notarize app bundle"
  # Extract the secrets we defined earlier as environment variables
  env:
    PROD_MACOS_NOTARIZATION_APPLE_ID: ${{ secrets.PROD_MACOS_NOTARIZATION_APPLE_ID }}
    PROD_MACOS_NOTARIZATION_TEAM_ID: ${{ secrets.PROD_MACOS_NOTARIZATION_TEAM_ID }}
    PROD_MACOS_NOTARIZATION_PWD: ${{ secrets.PROD_MACOS_NOTARIZATION_PWD }}
  run: |
    # Store the notarization credentials so that we can prevent a UI password dialog
    # from blocking the CI

    echo "Create keychain profile"
    xcrun notarytool store-credentials "notarytool-profile" --apple-id "$PROD_MACOS_NOTARIZATION_APPLE_ID" --team-id "$PROD_MACOS_NOTARIZATION_TEAM_ID" --password "$PROD_MACOS_NOTARIZATION_PWD"

    # We can't notarize an app bundle directly, but we need to compress it as an archive.
    # Therefore, we create a zip file containing our app bundle, so that we can send it to the
    # notarization service

    echo "Creating temp notarization archive"
    ditto -c -k --keepParent "target/mac/Espanso.app" "notarization.zip"

    # Here we send the notarization request to the Apple's Notarization service, waiting for the result.
    # This typically takes a few seconds inside a CI environment, but it might take more depending on the App
    # characteristics. Visit the Notarization docs for more information and strategies on how to optimize it if
    # you're curious

    echo "Notarize app"
    xcrun notarytool submit "notarization.zip" --keychain-profile "notarytool-profile" --wait

    # Finally, we need to "attach the staple" to our executable, which will allow our app to be
    # validated by macOS even when an internet connection is not available.
    echo "Attach staple"
    xcrun stapler staple "target/mac/Espanso.app"

Bonus: troubleshooting Notarization issues

While you are testing the notarization process, it might happen that the above GitHub Action step fails, with an error like:

Current status: Invalid....Processing complete
  id: <RANDOM-ID>
  status: Invalid

In these cases, you can view the notarization logs by using the following command (replacing <RANDOM-ID> with the actual one, which you can see in the step logs)

xcrun notarytool log <RANDOM-ID> --keychain-profile "notarytool-profile"

Conclusion

Your app should now be fully code-signed and notarized, great job! As a result, no more scary warnings will be shown to your users:

Acknowledgments

This article wouldn’t have been possible without this awesome article by Localazy for the code-signing steps and this GitHub comment for the Notarization part, kudos to Jan Bílek and Brad King!

Optimizing Lists in React - Solving Performance Problems and Anti-patterns

Federico Terzi — Wed, 16 Feb 2022 19:33:27 +0000

I'm Federico, a Software Engineer specialized in Frontend Development and System Programming. You can find out more about my work on Twitter, YouTube and GitHub.

This post originally appeared on my personal blog.

React is the most popular front-end framework, and that’s for a reason. Besides being funded by one of the largest companies on the planet, it’s also built around a few key concepts (one-way data flow, immutable data, functional components, hooks) that make it easier than ever to create robust applications. That said, it’s not without pitfalls.

It’s easy to write inefficient code in React, with useless re-renders being the common enemy. Usually, you start from a simple application and gradually build features on top of it. At first, the application is small enough to make the inefficiencies unnoticeable, but as the complexity grows, so does the component hierarchy, and thus, the number of re-renders. Then, once the application speed becomes unbearable (according to your standards), you start profiling and optimizing the problematic areas.

In this article, we are going to discuss the optimization process for lists, which are notorious sources of performance problems in React. Most of these techniques apply to both React and React Native applications.

Starting from a problematic example

We’ll start from a problematic example and gradually discuss the process of identifying and solving the different issues.

The proposed example is a simple list of selectable items, with a few performance problems. Clicking on an item toggles the selection status, but the operation is visibly laggy. Our goal is to make the selection feel snappy. You can find the complete code as follows (a Codesandbox is also available).

import { useState } from "react";

// Create mock data with elements containing increasing items
const data = new Array(100)
  .fill()
  .map((_, i) => i + 1)
  .map((n) => ({
    id: n,
    name: `Item ${n}`
  }));

export default function App() {
  // An array containing the selected items
  const [selected, setSelected] = useState([]);

  // Select or unselect the given item
  const toggleItem = (item) => {
    if (!selected.includes(item)) {
      setSelected([...selected, item]);
    } else {
      setSelected(selected.filter((current) => current !== item));
    }
  };

  return (
    <div className="App">
      <h1>List Example</h1>
      <List data={data} selectedItems={selected} toggleItem={toggleItem} />
    </div>
  );
}

const List = ({ data, selectedItems, toggleItem }) => {
  return (
    <ul>
      {data.map((item) => (
        <ListItem
          name={item.name}
          selected={selectedItems.includes(item)}
          onClick={() => toggleItem(item)}
        />
      ))}
    </ul>
  );
};

const ListItem = ({ name, selected, onClick }) => {
  // Run an expensive operation to simulate a load
  // In real-world JS applications, this could be either a custom
  // JS elaboration or a complex render.
  expensiveOperation(selected);

  return (
    <li
      style={selected ? { textDecoration: "line-through" } : undefined}
      onClick={onClick}
    >
      {name}
    </li>
  );
};

// This is an example of an expensive JS operation that we might
// execute in the render function to simulate a load.
// In real-world applications, this operation could be either a custom
// JS elaboration or just a complex render
const expensiveOperation = (selected) => {
  // Here we use selected just because we want to simulate
  // an operation that depends on the props
  let total = selected ? 1 : 0;
  for (let i = 0; i < 200000; i++) {
    total += Math.random();
  }
  return total;
};

If you want to practice, feel free to pause reading and try to spot the problems yourself first

Let’s dive into the analysis.

Missing key prop

The first thing we can notice from the console is that we are not passing the key prop when rendering the list items.

which is caused by this code:

{data.map((item) => (
  <ListItem
    name={item.name}
    selected={selectedItems.includes(item)}
    onClick={() => toggleItem(item)}
  />
))}

As you might already know, the key prop is critical for dynamic lists to work correctly in React, as it helps the framework identify which items have changed, are added, or are removed.

A common beginners’ anti-pattern is to solve the problem by passing the item’s index:

{data.map((item, index) => (
  <ListItem
    key={index}
    name={item.name}
    selected={selectedItems.includes(item)}
    onClick={() => toggleItem(item)}
  />
))}

Despite working for simple use-cases, this approach leads to multiple unexpected behaviors when the list is dynamic, with items being added or removed. For example, if you delete an item in the middle of a list at index N, then all list items located at positions N+1 will now have a different key. That causes React to “confuse” which mapped component belongs to which items. If you want to know more about the potential pitfalls of using the index as key, this article is a great resource.

Therefore, you should specify a key prop with something that uniquely identifies the item being rendered. If the data you’re receiving is coming from a backend, you might be able to use the database’s unique id as key. Otherwise, you could generate a client-side random id with nanoid when creating the items.

Luckily, each of our own items has it’s own id property, so we should handle it as follows:

{data.map((item) => (
  <ListItem
    key={item.id}
    name={item.name}
    selected={selectedItems.includes(item)}
    onClick={() => toggleItem(item)}
  />
))}

Adding the key solves the previous warning, but we still have a significant lag when selecting an item. It’s time to go serious and open the profiler.

Profiling the list

Now that we solved the key warning, we are ready to tackle the performance problem. At this stage, using a profiler can help to track down the slow areas and therefore guide our optimization, so that’s what we are going to do.

When working with React, there are two main profilers you can use: the browser’s built-in profiler, such as the one available inside Chrome’s Dev Tools, and the profiler provided by the React DevTools extension. Both of them are useful in different scenarios. From my experience, the React DevTools’ profiler is a good starting point, as it gives you a component-aware performance representation, which is helpful to track down the specific components that are causing problems, whereas the browser’s profiler works at a lower level and it’s mostly helpful in those cases where the performance problems are not directly related to a component, for example, due to a slow method or Redux reducer.

For this reason, we are going to start with the React DevTools’ profiler, so make sure to have the extension installed. Then, you can access the Profiler tool from Chrome’s dev tools > Profiler. Before starting, we are going to set up two settings that will help us in the optimization process:

In Chrome’s Performance tab, set CPU throttling to x6. That will simulate a slower CPU, making slowdowns much more evident.

In React DevTools Profiler tab, click on the Gear icon > Profiler > “Record why each component rendered while profiling”. This will help us track down the causes for useless re-renders.

Once the configuration is done, we are ready to profile our sample todo app. Go ahead and click on the Record button, then select some items in the list and, finally, hit stop recording. This is the result we obtain after selecting 3 items:

On the top right side, you see highlighted in red the commits, which, in short, are the renders that caused the DOM to update. As you can see, the current commit took 2671 milliseconds to render. By hovering on the various elements, we can tell that most of the time is spent rendering the list items, with an average of 26 milliseconds per item.

Spending 26 milliseconds rendering a single item is not inherently bad. As long as the entire operation takes less than 100ms, the action would still be perceived as snappy by the user. Our biggest problem is that selecting a single item causes all the items to be re-rendered, and that’s what we are going to tackle in the next section.

A question we should ask ourselves at this point is: what’s the expected number of items to re-render after an action? In this particular case, the answer is one, as the result of a click is a new item being selected, with none of the others being affected. Another scenario might be a single-selection list, where at most one item could be selected at any given time. In that case, clicking on an item should cause the re-render of two items, as we need to render both the selected one and the one being unselected.

Preventing re-renders with React.memo

In the previous section, we discussed how selecting a single item causes the entire list to be re-rendered.
Ideally, we would like to re-render only the items whose "looks" are affected by the new selection.
We can do that using the React.memo higher-order component.

In a nutshell, React.memo compares the new props with the old ones and, if they are equal, it reuses the previous render.
Otherwise, if the props are different, it re-renders the component.
It's important to note that React executes a shallow comparison of the props, which must be taken into account when passing objects and methods as props.
You can also override the comparison function, though I would advise against it, as it makes the code less maintainable (more on this later).

Now that we know the basics of React.memo, let's create another component by wrapping the ListItem with it:

import { memo } from "react";

const MemoizedListItem = memo(ListItem);

We can now use MemoizedListItem instead of ListItem in the list:

  {data.map((item) => (
    <MemoizedListItem
      key={item.id}
      name={item.name}
      selected={selectedItems.includes(item)}
      onClick={() => toggleItem(item)}
    />
  ))}

Nice! We now have memoized the ListItem. If you go ahead and try the application, you'll notice something is wrong...
The application is still slow!

If we open up the profiler as we previously did and record a selection, we should be presented with something like the following:

As you can see, we are still re-rendering all the items! Why is it happening?
If you hover on one of the list items, you'll see the "Why did this render?" section. In our case, it says Props changed: (onClick),
which means our items are re-rendering due to the onClick callback we are passing to each item.

As we previously discussed, React.memo does a shallow comparison of the props by default.
Which basically means calling the strick equality operator === over each prop. In our case, the check would
be roughly equivalent to:

function arePropsEqual(prevProps, nextProps) {
  return prevProps.name === nextProps.name &&
         prevProps.selected === nextProps.selected &&
         prevProps.onClick === nextProps.onClick
}

While name and selected are compared by value (because they are primitive types, string and boolean respectively), onClick is compared
by reference (being a function).
When we created the list items, we passed the onClick callback as an anonymous closure:

onClick={() => toggleItem(item)}

Every time the list re-renders, each item receives a new callback function.
From an equality perspective, the callback has changed, and therefore the MemoizedListItem is re-rendered.

If the equality aspect is still unclear to you, go ahead and open the JS console inside your browser.
If you type true === true, you'll notice that the result is true.
But if you type (() => {}) === (() => {}), you'll get false as result.
That's because two functions are equal only if they share the same identity, and
every time we create a new closure we generate a new identity.

Therefore, we need a way to keep the identity of the onClick callback stable to prevent useless re-renders,
and that's what we are going to discuss in the next sections.

A common anti-pattern

Before discussing the proposed solution, let's analyze a common (anti-)pattern being used in these cases.
Given that the React.memo method accepts a custom comparator, you might be tempted to provide one that
artifically excludes onClick from the check. Something like the following:

const MemoizedListItem = memo(
  ListItem,
  (prevProps, nextProps) =>
    prevProps.name === nextProps.name &&
    prevProps.selected === nextProps.selected
    // The onClick prop is not compared
);

In this case, even with a changing onClick callback, the list items won't be re-rendered unless name or selected are updated.
If you go ahead and try this approach, you'll notice the list feels snappy now, but something is wrong:

As you can see, selecting multiple items doesn't work as expected now, with items being randomly selected and unselected.
This is happening because the toggleItem function is not pure, as it depends on the previous value of the selected items.
If you exclude the onClick callback check from the React.memo comparator, then your components might receive an outdated (stale)
version of the callback, causing all those glitches.

In this particular case, the way the toggleItem is implemented is not optimal and we can easily convert it to a pure function
(in fact, we are going to do that in the next section). But my point here is: by excluding the onClick callback from the memo
comparator, you're exposing the application to subtle staleness bugs.

Some might argue that as long as the onClick callback is kept pure, then this approach is perfectly acceptable.
Personally, I consider this an anti-pattern for two reasons:

In complex codebases is relatively easy to transform a pure function into a non-pure one by mistake.
By writing a custom comparator, you're creating an additional maintenance burden. What if the ListItem needs to accept another color parameter in the future? Then, you'll need to refactor to the comparator, as shown below. If you forget to add it (which is relatively easy in complex codebases with multiple contributors), then you are again exposing your component to staleness bugs.

const MemoizedListItem = memo(
  ListItem,
  (prevProps, nextProps) =>
    prevProps.name === nextProps.name &&
    prevProps.selected === nextProps.selected &&
    prevProps.color === nextProps.color
);

If a custom comparator is not advisable, what should we do to solve this problem then?

Making callback identities stable

Our goal is to use the "base" version of React.memo without a custom comparator.
Choosing this path will both improve the maintainability of the component and its robustness against future changes.
For the memoization to work correctly though, we'll need to refactor the callback to keep its identity stable, otherwise
the equality check performed by React.memo will prevent the memoization.

The traditional way to keep function identities stable in React is to use the useCallback hook.
The hook accepts a function and a dependency array, and as long as the dependencies won't change, neither will the identity of the callback.
Let's refactor our example to use useCallback:

Our first attempt is to move the anonymous closure () => toggleItem(item) inside a separate method inside useCallback:

const List = ({ data, selectedItems, toggleItem }) => {
  const handleClick = useCallback(() => {
    toggleItem(??????) // How do we get the item?
  }, [toggleItem])

  return (
    <ul>
      {data.map((item) => (
        <MemoizedListItem
          key={item.id}
          name={item.name}
          selected={selectedItems.includes(item)}
          onClick={handleClick}
        />
      ))}
    </ul>
  );
};

We are now facing a problem: previously, the anonymous closure captured the current item in the .map iteration and then passed it to the toggleItem
function as an argument. But now, we are not declaring the handleClick handler inside the iteration, so how can we access the "selected item" in the callback?
Let's discuss a possible solution:

Refactoring the ListItem component

Currently, the ListItem's onClick callback doesn't provide any information about the item being selected.
If it did, we would be able to easily solve this problem, so let's refactor the ListItem and List components to provide this information.

Firstly, we change the ListItem component to accept the full item object, and given that the name prop is now redundant we remove it.
Then, we introduce an handler for the onClick event to also provide the item as argument. This is our end result:

const ListItem = ({ item, selected, onClick }) => {
  // Run an expensive operation to simulate a load
  // In real-world JS applications, this could be either a custom
  // JS elaboration or a complex render.
  expensiveOperation(selected);

  return (
    <li
      style={selected ? { textDecoration: "line-through" } : undefined}
      onClick={() => onClick(item)}
    >
      {item.name}
    </li>
  );
};

As you can see, the onClick now provides the current item as a parameter.

But wait! You used an anonymous closure again in the li's onClick handler, shouldn't we avoid them to prevent re-renderings?
While we could create another memoized callback with useCallback inside the ListItem component to handle the click event, that would offer no performance improvements in this case.
The problem with the anonymous closure we discussed earlier in the List item was that it broke the React.memo memoization for the MemoizedListItem. Given that we are not memoizing the li element, then there is no performance benefit from having a stable identity for this callback.

We can then refactor the List component to pass the item prop instead of name and to make use of the newly available item information in the handleClick callback:

const List = ({ data, selectedItems, toggleItem }) => {
  const handleClick = useCallback(
    (item) => {  // We now receive the selected item
      toggleItem(item);
    },
    [toggleItem]
  );

  return (
    <ul>
      {data.map((item) => (
        <MemoizedListItem
          key={item.id}
          item={item}  // We pass the full item instead of the name
          selected={selectedItems.includes(item)}
          onClick={handleClick}
        />
      ))}
    </ul>
  );
};

Nice! Let's go ahead and try the refactored version:

It works... but it's still slow! If we open up the profiler, we can see the whole list is still being rendered:

As you can see from the profiler, the onClick identity is still changing! That means our handleClick identity is being changed at every re-render.

Another common anti-pattern

Before diving into the proper solution, let's discuss a common anti-pattern used in these cases.
Given that the useCallback accepts a dependency array, you could be tempted to specify an empty one to keep the identity fixed:

  const handleClick = useCallback((item) => {
    toggleItem(item);
  }, []);

Despite keeping the identity stable, this approach suffers from the same staleness bugs we discussed in previous sections.
If we run it, you'll notice the items get unselected as it happened when we specified the custom comparator:

In general, you should always specify the correct dependencies in useCallback, useEffect and useMemo, otherwise, you're
exposing the application to potentially hard-to-debug staleness bugs.

Solving the toggleItem identity problem

As we previously discussed, the problem with our handleClick callback is that its toggleItem dependency identity changes at each render, causing it to re-render as well:

  const handleClick = useCallback((item) => {
    toggleItem(item);
  }, [toggleItem]);

Our first attempt is to wrap toggleItem with useCallback as we did with handleClick:

  const toggleItem = useCallback(
    (item) => {
      if (!selected.includes(item)) {
        setSelected([...selected, item]);
      } else {
        setSelected(selected.filter((current) => current !== item));
      }
    },
    [selected]
  );

This does not solve the problem though, as this callback depends on the external state variable selected, which changes every time setSelected is called. If we want its identity to remain stable, we need a way to make toggleItem pure. Luckily, we can use useState's functional updates to accomplish our goal:

  const toggleItem = useCallback((item) => {
    setSelected((prevSelected) => {
      if (!prevSelected.includes(item)) {
        return [...prevSelected, item];
      } else {
        return prevSelected.filter((current) => current !== item);
      }
    });
  }, []);

As you can see, we wrapped our previous logic inside the setSelected call, which in turn provides the previous state value we need to compute the new selected items.

If we go ahead and run the refactored example, it works and it's also snappy! We can also run the usual profiler to get a sense of what's happening:

Hovering on the item being rendered:

Hovering on the other items:

As you can see, after selecting an item we only render the current one being selected now, while the others are being memoized.

A note on functional state updates

In the example we just discussed, converting our toggleItem method to the functional mode of useState was relatively trivial.
In real-world scenarios, things might not be as straightforward.

For example, your function might depend on multiple state pieces:

  const [selected, setSelected] = useState([]);
  const [isEnabled, setEnabled] = useState(false);

  const toggleItem = useCallback((item) => {
    // Only toggle the items if enabled
    if (isEnabled) {
      setSelected((prevSelected) => {
        if (!prevSelected.includes(item)) {
          return [...prevSelected, item];
        } else {
          return prevSelected.filter((current) => current !== item);
        }
      });
    }
  }, [isEnabled]);

Every time the isEnabled value changes, your toggleItem identity will change as well.
In these scenarios, you should either merge both sub-states into the same useState call, or even better, convert it to a useReducer one.
Given that useReducer's dispatch function has a stable identity, you can scale this approach to complex states.
Moreover, the same applies to Redux's dispatch function, so you can move the item toggle logic at the Redux level and convert our toggleItem function to something as:

  const dispatch = useDispatch();

  // Given that the dispatch identity is stable, the `toggleItem` will be stable as well
  const toggleItem = useCallback((item) => {
    dispatch(toggleItemAction(item))
  }, [dispatch]);

Virtualizing the list?

Before closing the article, I wanted to briefly cover list virtualization, a common technique used to improve performance for long lists.
In a nutshell, list virtualization is based on the idea of rendering just a sub-set of the items in a given list (generally the currently visible ones) and deferring the others.
For example, if you have a list with a thousand items but only 10 are visible at any given time, then we might only render these 10 first, and the others can be rendered on-demand when needed (i.e. after scrolling).

List virtualization offers two main advantages compared to rendering the entire list:

Faster initial start time, as we only need to render a subset of the list
Lower memory usage, as only a subset of the items is being rendered at any given time

That said, list virtualization is not a silver bullet you should always use, as it increases complexity and can be glitchy.
Personally, I'd avoid virtualized lists if you are only dealing with hundreds of items, as the memoization techniques we discussed in this article are often effective enough (older mobile devices might require a lower threshold). As always, the right approach depends on the specific use case, so I'd highly recommend profiling your list before diving into more complex optimization techniques.

We are going to cover virtualization in a future article. In the meanwhile, you can read more about virtualized lists in React, with libraries like react-window, and in React Native, with the built-in FlatList component.

Conclusion

In this article, we covered list optimization in depth. We started from a problematic example and gradually solved most of the performance problems.
We also discussed the main anti-patterns you should be aware of, along with potential ways to solve them.

In conclusion, lists are often the cause of performance problems in React, as all items are being re-rendered every time something changes by default.
React.memo is an effective tool to mitigate the issue, but you might need to refactor your application to make your props' identities stable.

The final code is available in this CodeSandbox if you're interested.

PS: there's one small useMemo optimization left to add in our example, can you spot it yourself? :)

12 Rust Tips and Tricks you might not know yet

Federico Terzi — Thu, 20 Jan 2022 07:56:00 +0000

I'm Federico, a Software Engineer specialized in Frontend Development and System Programming. You can find out more about my work on Twitter, YouTube and GitHub.

This post originally appeared on my personal blog.

Rust is a great programming language: reliable, fast, enjoyable, but also rather complex. Over the past two years, I’ve been using it both professionally and on side projects (such as Espanso) and, over that time, I stumbled upon many useful patterns and crates that I wish I knew when I first started learning it.

Using Cow<str> as return type

Sometimes you need to write methods that accept a string slice (&str) and conditionally return either a modified version of it or the original one. For these cases, you might use Cow<str>, so that you only allocate new memory when necessary.

use std::borrow::Cow;

fn capitalize(name: &str) -> Cow<str> {
    match name.chars().nth(0) {
        Some(first_char) if first_char.is_uppercase() => {
            // No allocation is necessary, as the string
            // already starts with an uppercase char
            Cow::Borrowed(name)
        }
        Some(first_char) => {
            // An allocation is necessary, as the old string
            // does not start with an uppercase char
            let new_string: String = first_char.to_uppercase()
              .chain(name.chars().skip(1))
              .collect();

            Cow::Owned(new_string)
        },
        None => Cow::Borrowed(name),
    }
}

fn main() {
    println!("{}", capitalize("bob"));   // Allocation
    println!("{}", capitalize("John"));  // No allocation
}

Crossbeam channels instead of the standard ones

The crossbeam crate offers a powerful alternative to standard channels with support for the Select operation, timeouts, and more. Similar to what you get out of the box in Golang and traditional Unix sockets.

use crossbeam_channel::{select, unbounded};
use std::time::Duration;

fn main() {
    let (s1, r1) = unbounded::<i32>();
    let (s2, r2) = unbounded::<i32>();
    s1.send(10).unwrap();

    select! {
        recv(r1) -> msg => println!("r1 > {}", msg.unwrap()),
        recv(r2) -> msg => println!("r2 > {}", msg.unwrap()),
        default(Duration::from_millis(100)) => println!("timed out"),
    }
}

Golang-like defer operator with Scopeguard

If you are coming from Golang, you might miss the "defer" operator for certain use-cases (like freeing memory when working with raw pointers or closing a socket).

In Rust (besides the RAII pattern), you can use the scopeguard crate to easily implement "cleaup" logic.

#[macro_use(defer)] extern crate scopeguard;

fn main() {
    println!("start");
    {
        // This action will run at the end of the current scope
        defer! {
           println!("defer");
        }

        println!("scope end");
    }
    println!("end");

    // Output:
    // start
    // scope end
    // defer
    // end
}

Cargo-make for packaging

Build scripts are great for a lot of things, but usually not for packaging. My favorite solution for that is Cargo Make by sagiegurari, a Rust-based task runner and build tool.

Customize and chain Panic handlers

Panic handlers (called hooks) can be overridden and chained, which becomes particularly useful when setting up custom error reporting and logging for your application.

use std::panic::{set_hook, take_hook};

fn main() {
    let prev_hook = take_hook();

    set_hook(Box::new(move |panic| {
        println!("custom logging logic {}", panic);

        prev_hook(panic);    
    }));

    let prev_hook = take_hook();

    set_hook(Box::new(move |panic| {
        println!("custom error reporting logic {}", panic);

        prev_hook(panic);    
    }));

    panic!("test")

    // Output:
    // custom error reporting logic panicked at 'test', src/main.rs:20:5
    // custom logging logic panicked at 'test', src/main.rs:20:5
}

Use Rust Analyzer on VSCode

The Rust analyzer VSCode extension by matklad is significantly better than the “official” Rust one. Unfortunately, it’s still showing as a second result on the extensions marketplace, misguiding a lot of beginners.

Use impl Trait when working with Closures

Prefer impl Fn/FnOnce/FnMut to pass a closure to a function (called impl Trait) instead of a generic when possible to keep the signature clean. For non-trivial cases, you might need to box the closure with Box<Fn()>, but keep in mind you’ll pay an additional overhead.

// Instead of this

fn setup_teardown_generic<A: FnOnce()>(action: A) {
    println!("setting up...");

    action();

    println!("tearing down...")
}

// Use this

fn setup_teardown(action: impl FnOnce()) {
    println!("setting up...");

    action();

    println!("tearing down...")
}

// As a note, this pattern is very useful inside tests
// to create/destroy resources.

fn main() {
    setup_teardown(|| {
        println!("Action!");
    })

    // Output:
    // setting up...
    // Action!
    // tearing down...
}

Enable Clippy on Save for VSCode

If you’re using VSCode + Rust Analyzer, I highly suggest going into the settings > Rust Analyzer > Check On Save: Command and setting "clippy" as the new default instead of "check". Same UX, better warnings.

Use “thiserror” and “anyhow” for idiomatic error handling

Use the thiserror and anyhow crates for idiomatic error handling. You should use thiserror when the consumer needs to conditionally act based on the error, anyhow otherwise. A good guideline is “use thiserror for libraries and anyhow for applications”.

Using dbg!() macro instead of println!()

Use the dbg!() macro instead of println!() when debugging. Less code, more useful information.

fn main() {
    let var1 = 2;

    println!("{}", 2); // Output: 2
    dbg!(var1);        // Output: [src/main.rs:5] var1 = 2
    dbg!(var1 * 2);    // Output: [src/main.rs:6] var1 * 2 = 4
}

include_str!() and include_bytes!() macros

Use the include_str!() and include_bytes!() macros to read the content of a file at compile time and store it inside a const. Useful to avoid messing with multiline string literals.

// Both of these files are read at *compile time*
const FILE_CONTENT: &str = include_str!("./path/to/the/file.txt");
const BINARY_FILE_CONTENT: &[u8] = include_bytes!("./path/to/image.png");

fn main() {
    println!("{}", FILE_CONTENT);  // Output: file content as string
}

Integrating with C/C++ code

If you need to integrate C/C++ code with Rust, the cc crate and the proper build script can get you pretty far. For example, I’ve used them to integrate wxWidgets, a popular C++ gui framework, with my project Espanso (see the build script)

// Inside the build script (build.rs)

fn main() {
  println!("cargo:rerun-if-changed=src/native.c");
  println!("cargo:rerun-if-changed=src/native.h");
  cc::Build::new()
    .include("src/native.h")
    .file("src/native.c")
    .compile("nativemodule");
  println!("cargo:rustc-link-lib=static=nativemodule");
}

// Then, in another Rust file (for example, ffi.rs)

#[link(name = "nativemodule", kind = "static")]
extern "C" {
  pub fn your_cool_c_module();
}

Thanks for reading! If you like these topics, make sure to follow me on Twitter and YouTube to stay updated with the latest articles and videos.

Rust vs C++, which is better and why?

Federico Terzi — Mon, 03 Jan 2022 21:11:22 +0000

I'm Federico, a Software Engineer specialized in Frontend Development and System Programming. You can find out more about my work on Twitter, YouTube and GitHub.

This post originally appeared on my personal blog.

This question comes up a lot lately, especially when considering if learning Rust is worth it or not, and so I thought it could be a wonderful opportunity to write a new article, discussing the differences between the two, as well as what they share in common.

Similarities

Both Rust and C++ are system programming languages, which means they can be used to write low-level code like kernels and firmware for microcontrollers. But compared with C, they offer a lot of abstractions that make it possible to go high-level as well, for example, writing games and web applications.

Another similarity is that neither of them uses a garbage collector to manage memory, which makes the code much more predictable, efficient, and in many cases faster. Of course, if you ever used C, you will know that managing memory yourself is hard. Besides the cognitive overhead, you are also running the risk of causing segmentation faults and undefined behaviors.

Memory and Thread safety

For this reason, modern C++ introduced concepts like smart pointers as a way to mitigate those memory-related bugs, but despite the significant improvements, they are limited in the number of guarantees they can offer. Rust takes it a step further and introduces the borrow checker, a component bundled within the compiler itself that makes sure that a reference does not outlive the data they refer to, preventing entire classes of memory unsafety bugs.

Another big selling point for Rust is its rich type system, which makes it possible to prevent data races at compile time. It does so by introducing two special traits, Sync and Send, which are used by the compiler to determine whether a multi-threaded operation is safe or not. And while sharing some memory between threads is possible in Rust, the compiler will stop you from building a program that does so unsafely, preventing data races even before the program starts. For example, if you want to mutate a variable from multiple threads, the compiler will require you to wrap it with a Mutex or something equivalent, because in general, mutating an unsynchronized variable from multiple threads is unsafe, unless a synchronization primitive or atomic operation is used.

Unsafe Rust

Up to this point, we discussed the features of the so-called “safe Rust”, which provides guarantees like memory safety and prevents undefined behavior, but there is also another “version” of the language known as unsafe Rust, which basically gives you superpowers at the price of losing all those safety guarantees.

Are you wondering why this is needed? Well, there are mainly two reasons: if you want to interact with the low-level aspects of the operating system or hardware, those operations are inherently unsafe, so the “safe Rust” compiler, which is the one that tries to give you guarantees, is not able to do so. Therefore, if you still want to execute them, you have to explicitly tell the compiler to trust you and give up those safety guarantees, entering the “unsafe” side of Rust.

The other reason is that when analyzing the code, the compiler is very conservative. From a guarantees point of view, it’s much better to block a valid program than to make an incorrect one pass the compilation step. Thus, there are times in which we might want to bypass those checks, and in order to do so, we need to enter the “unsafe” side as well.

In a way, unsafe Rust and C++ are very similar. The main difference is that Rust programmers usually avoid the “unsafe” side as much as possible unless interfacing with the low-level aspects of the operating systems or when absolutely certain that an operation is correct, and this greatly reduces the surface for memory problems.

Package management and ecosystem

An area in which Rust is arguably better than C++ is package management. If you have ever worked with Python or JavaScript you will feel right at home with cargo, the official Rust package manager. Installing a package is just a matter of adding a line into cargo.toml file, whereas in C++ using an external library can be a huge pain, especially if targeting multiple operating systems. There have been some attempts to bring modern package management to C++, such as Conan and vcpkg, but they are far from being standardized or easy to use as cargo.

With that being said, the C++ ecosystem is huge, much bigger than the Rust counterpart, as the former has been around for multiple decades. In other words, there are many more libraries for C++ than for Rust, with the latter sometimes lacking a suitable one.

The good news is that Rust has a very good Foreign Function Interface, which means you can interface with C code very easily from Rust, and thus, also interface with C++ libraries by exposing a C API from them. Unfortunately, this is not always possible, especially in complex cases, but there are some ongoing attempts to make creating bindings easier. An example is the autocxx library, which is being developed by the Google Chrome team to investigate whether parts of the browser could be developed using Rust in the future.

Macros

Another interesting difference between the two languages is the macro system, which in Rust is much more powerful and safer. First of all, Rust ships with two kinds of macros: declarative and procedural. The former type is similar to the traditional C/C++ macros, with the difference that macros are hygenic, meaning that they cannot interfere with variables outside their scope and therefore don’t cause any unwanted side effects. On the other hand, procedural macros are completely different, much more powerful and also complex. They can be basically thought of as compiler plugins that receive the program syntax tree as input, manipulate it, and then return the enriched syntax tree as output. This makes it possible to create annotations, similarly to Java, that enrich the code at compile time.

Conclusion

To conclude, which of the two languages is better? As always, it depends! But these are the most important takeaways:

Rust is likely to be the future of system programming, and the proof is that many of the big players (Microsoft, Apple, Google) are moving in that direction, gradually integrating Rust with their products. Don’t get me wrong, C++ is far from being dead and is not going away anytime soon due to the incredibly vast amount of legacy code built with it, but an increasing number of companies are choosing Rust over C++ for new products.

My theory is that in 10-years’ time, most C++ jobs will be focused on maintaining legacy software rather than creating new products. But of course, that’s only my opinion and I might be wrong :)

If you liked the article, you can follow me on Twitter or Youtube!