# Refaming Rust

!!! note Re·fam·ing
    /rē fām iNG/
    *noun* The act of undoing defamation
    *Etymology* I made it the fuck up

Despite its status as [the most loved programming language for seven years in a row](https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages), the Rust programming language manages to attract a lot of haters. Some of the reasons for hating it are legitimate. For instance, it has slow compile times, a difficult learning curve, and a number of features that still require nightly to use. Plus it may not have some of the more "killer" features that make other languages stand out among the rest. It doesn't have higher kinded types or variadic templates, and it likely won't for a while. It also doesn't have inheritance of structs, and it likely won't for a while as this was a deliberate design choice.

Nevertheless, though there are many good reasons to dislike Rust, there seems to be a lot of bullshit reasons floating around as well. This document aims to dispel a number of myths spread about the language, particularly on sites like 4chan, where the language remains a divisive topic.

## Myth 1: Rust makes you transgender/All Rust users are transgender

You cannot have a discussion about Rust on /g/ without someone bringing up trans people. This has been a meme ever since users first learned of Rust's Code of Conduct, which asks that contributors to certain Rust projects and participants in various Rust communities, not engage in certain disrespectful behavior (i.e. deliberately using the wrong pronouns of a trans person). Certainly, there are a number of Rust users that are transgender. But how numerous are they really?

It turns out the Rust team was interested in the answer to this question too. Or more specifically, they were interested in a variety of demographic data about users, including race, sexuality, and of course gender identity. In the [Rust survey 2018](https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html), users were asked if they belonged to any of a number of underrepresented minority groups. This is how they responded:
![Statistics of underrepresented minorities among Rust users](https://blog.rust-lang.org/images/2018-11-RustSurvey/24-Underrepresented.png)

Trans people account for just 2.85% of Rust users. Non-heterosexual people account for just 7.71%. A full 92% of Rust users do not identify with any underrepresented minority groups. Based on these statistics, if you pick a Rust user at random, you're likely to find someone who is straight, white, male, and identifies as his birth sex. If this describes you, then you are not excluded from the community and never have been. You can continue to enjoy the identity you had before becoming a Rust user. Just be considerate of your colleagues who may have different identities. 

## Myth 2: You can't use certain constants in Rust.

For those who wish to contribute to the development of the Rust programming language, there is a style checking script used to keep a number various patterns out of the codebase which the maintainers would consider to be code smells. These include things like leaving "TODOs" in the codebase, indenting with tabs instead of spaces, or ending lines with carriage returns. They also don't want to see the use of magic numbers. This would mean that you shouldn't start putting in numeric constants like `0xCAFEBABE` in the your source code. The Rust compiler does not parse Java bytecode files, so it does not need to recognize the magic number used to identify them. It does not need to use any other magic numbers for that matter.

But suppose you want to use those magic numbers in your own code. Maybe you'd like to rewrite OpenJDK in Rust... **There are no restrictions on this**. You will not even receive a compiler warning. The Rust compiler team does not care about what constants you use in your codebase. They only care about the ones that they have to deal with in their own project. Because it's *their* project, and they can put whatever restrictions they want on it, and it won't affect you unless you want to work with them.

## Myth 3: The unsafe keyword means nothing in a program is safe

Whenever a critic of Rust learns that the `unsafe` keyword is necessary to perform some task in Rust, or that it is the most pragmatic solution to certain tasks (i.e. creating a linked list), the go-to response seems to be that this defeats the purpose of using Rust. After all, Rust's primary benefit over languages like C and C++ is that it's safe, and if you can't guarantee the safety of one line of code in the program, then obviously the whole thing's compromised, right? Well, no. Rust still guarantees that the rest of your program can't create undefined behavior like corrupting memory.

If memory was corrupted at any point in your program, it happened because of something that occurred in an unsafe block. But using an unsafe block doesn't guarantee memory corruption. It just means you have to manually verify that it won't cause any problems. Does that mean that Rust can never be 100% safe? Maybe, but that was never the point. The point of using Rust is to make safer programs than you could with other languages. In the same way that you are safer in a car crash by using a seat belt, you are also safer using Rust (and minimizing the use of the unsafe keyword to where it's necessary) than you are using C or C++. And similarly, just as you can die while wearing a seatbelt, you can create a segfault in Rust or a buffer overflow. But it's much less likely to happen. And if it does, it'll be much easier to find, since it can only result from an unsafe block.

## Myth 4: Rust doesn't support Unicode!

There are a few screenshots spreading around /g/ depicting the Rust programs [exa](https://github.com/ogham/exa) and [ripgrep](https://github.com/BurntSushi/ripgrep) struggling to process certain characters outside the ASCII 7-bit range. As these characters all have associated Unicode code points, it would appear to an uneducated viewer that the issue lies with the Rust programs not being able to understand Unicode. Except there is only one problem: Rust's built-in string types all use Unicode. Specifically, `str` and `String` use UTF-8 encoding internally, while `OsStr` and `OsString` will use whichever encoding is used natively by the operating system's available syscalls. Rust is extremely Unicode-aware. Which creates some interesting problems **when speaking to an operating system that isn't**.

Below we will find two screenshots that both show interesting behavior when executing exa and ripgrep
![exa screws up Greek characters](https://desu-usergeneratedcontent.xyz/g/image/1677/23/1677234648301.png)
![exa and ripgrep screw up the character ğ](https://desu-usergeneratedcontent.xyz/g/image/1678/88/1678882818872.png)

Let's take a look at the first screenshot. All of the Greek filenames are translated into a very interesting repeating pattern of `οΏ½`. Why these three characters? Well, let's assume that whatever Rust is reading, it isn't UTF-8. There are two ways to deal with this when trying parse this into a string type that expects UTF-8. One is to panic, the other is to swap them out with the [unicode replacement character](https://www.fileformat.info/info/unicode/char/fffd/index.htm). In UTF-8, this is represented by the byte sequence `0xEF 0xBF 0xBD`. So what happens when those bytes are then re-encoded into another format? Well, in [ISO 8859-7](https://en.wikipedia.org/wiki/ISO/IEC_8859-7), this encodes the string `οΏ½` as seen in the first screenshot. And in [ISO 8859-9](https://en.wikipedia.org/wiki/ISO/IEC_8859-9), it should be encoded as `�`, which we see in the second screenshot.

Neither ISO 8859-7 nor ISO 8859-9 are methods of encoding Unicode characters. They are among a number of character sets that extended upon the base 7-bit ASCII to enable support for different languages. But since they all used the same code points for different characters, they were abandoned in favor of Unicode, which can encode all of them. Using these character sets over Unicode is not the default behavior for modern computers. You have to change your operating system's locale settings to not use UTF-8 encoding, which may break other applications, even ones not written in Rust. Hypothetically, a Rust application could be programmed to function correctly in the presence of these esoteric locales, but why should it? You're the ones not using Unicode, not Rust!

## Myth 5: Rust always panics when out of memory!

This is a myth that used to be true, but is no longer the case thanks to some stabilized APIs. If you want to allocate heap memory in Rust, and handle errors should the allocation fail, your best option currently is to first create a `Vec`. The functions `Vec::try_reserve` and `Vec::try_reserve_exact` will attempt to allocate enough memory on the heap for a specified number of elements, and return a `Result<(), TryReserveError>` indicating the success or failure of the allocation. There are no panics, and you can match on the `Result` value to perform whatever error handling you want.

Currently, there are also some Nightly-only APIs that allow failable allocation with `Box` in the form of `Box::try_new`. This isn't stable yet, so if you don't want to use the Nightly compiler, your best option for obtaining a `Box` in this manner is to first create a `Vec`, and then use `Vec::into_boxed_slice`