path: root/src/blog/2025-06-13-cargo-culture-shock/cargo-culture-shock.md

# Cargo culture shock 🦀

After a long adventure
[porting my cube solver to the web](../2025-06-06-webdev), I decided to
try out something completely different, like learning a new language.
Rust is one on my to-do list, and it has been there for more than 10
years - I remember reading about it in my first year in university,
so it must have been 2013 or early 2014.

So I started by quickly reading through the first few chapters of
[the book](https://doc.rust-lang.org/book/) to get an idea of the basic
syntax. Before I move on to implementing something, I thought I could
share my very early impression of the language and the tooling around it.

*Note: this is a relaxed write-up and I have a very superficial
understanding of the topic. I am going to use strong words for the things
that I did not like, but there are many things I like about Rust so
far. In fact, my first impression of the language, the documentation and
the tools is very positive! Keep this in mind while reading this post.*

## What is Rust about?

Before getting started with the Rust book, my impression was that Rust
was mostly about *safety* as in *memory safety*, and that it achieved
this by enforcing strict rules, leading to more correct programs overall.

But [the foreword](https://doc.rust-lang.org/book/foreword.html) says "the
Rust programming language is fundamentally about *empowerment*". Uh, that's
weird. I was expecting "something something *safety*". And actually,
I was hoping for "something something *correctness*".  Definitely not
"something something *empowerment*". *Empowerment* sounds like one of
those meaningless words that managers use when they have nothing to say.

Anyway, empowerement it is. Let's move on to actually using the thing.

## Installation

The officially endorsed way of installing Rust is the following:

```
curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh
```

The horror, the horror! Is this really what they suggest? The very thing
that *everyone* told you not to do in nerd forums until a few years ago,
even worse than copy-pasting commands from the internet, is now THE
suggested way of installing software? Seriously, piping a random web
page into `sh`?

I don't know what this script does, is it going to download even more
random shit from the internet? (Answer: yes, it is!) Is it going to fuck
up my environment by puking configuration lines into my .bashrc? (Answer:
yes, it is!)

But ok, what do I know. Maybe I am just living in the past, I should
embrace the future, because package managers and `make && make install`
*are so 1999, man*. So I took a deep breath an run the command.
Luckily the script kindly asked "do you want me to fuck up your
environment? [default: Yes]". I may be paraphrasing this, it probably
mentioned `.bash_rc` and `.profile`. Anyway, you can easily say "no"
and skip this fuckery. And then manually update a couple of environment
variables in your shell configuration file, which is what the script was
trying to do. I guess developers today are not expected to know how to
do this.

The installation was quick and everything went fine. Moving on!

## Cargo cult

[Cargo](https://doc.rust-lang.org/book/ch01-03-hello-cargo.html) is
Rust's build system and all-in-one tool. It can create a new project
with a default folder structure, compile code (running `rustc` under
the hood`), run tests, and more. Oh and it is also a *package manager*,
which apparently is something modern programming languages decided they
needed - more on that later.

I don't always like these kind of tools, becase they tend to do a lot of
things that you don't understand with the files in the current directory.
Like vomiting generated files that you are supposed to check into your
[VCS](https://en.wikipedia.org/wiki/Version_control) - which kinda
defeats the purpose of *generating* files in the first place, doesn't it?

Luckily, Cargo does not do too much of this. It generates an `src` folder
with a simple "hello world" program, a pretty minimal `Cargo.toml`
configuration file, and it initializes a git repo. All reasonable,
and most importantly easy to understand.

On the first run of `cargo build` it also generates a `target` folder
for the build artifacts (already in `.gitignore`) and it generates
only one of those vomit files that I am supposed to check into git
(`Cargo.lock`), which I promptly added to .gitignore. Apparently it is
mainly about dependencies, and I'd rather not use any for now.  So all
in all I am satisfied with this process.

About dependencies, you can specify some packages, or *crates*, that your
projects depends on. These *crates* are going to be downloaded as they are
needed from [crates.io](https://crates.io/).  You can of course specify
some constraints on the version for each specific crate, like "at least
2.0" or "at least 0.8.5, but less than 0.9.0". Here is where `Cargo.lock`
comes into play: if there is more than one version available for a given
crate that satisfies the contraints you impose in `Cargo.toml`, the first
time a specific version is used it gets written to `Cargo.lock`, so that
you will keep using that version even if a new one becomes available.
You are supposed to check in this file to git so other developers working
on the same project will use exactly the same version of each dependency.

I can't quite understand this. If I don't want to update to a later
(minor) version of the dependency, I can already specify this in
`Cargo.toml`. If instead I impose more relaxed requirements, then it
means that any version satisfying those requirements is fine, and I
in this case *I do want* to try different versions within the allowed
range, to make sure that my assumptions are correct. So I am confused
about why this Cargo.lock business is needed at all.  But I guess if
the time ever comes that I need to include dependencies in my project -
probably in the far future, *right?* - then I can just specify an exact
version and happily ignore `Cargo.lock`.

Anyway, coming from a mostly C and C++ background where there is no
standard way of including dependencies, all of this is certainly quite
interesting.

## Dependencies?

Chapter 2 contains a simple code example.
[This part](https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html#generating-a-secret-number)
caught my attention:

"Rust doesn't yet include random number functionality in its standard library."

Uh, ok. And then people complain about C having a small standard library.
It then continues:

"However, the Rust team does provide a
[`rand` crate](https://crates.io/crates/rand) with said functionality."

Ok, but... if this is provided by the Rust team, why not including it in
the standard library? Maybe it is still in beta, Rust is not a "finished"
project as far as I understand. I would think 15 years is enough to ship
a random number generator, though.

The tutorial tell us to add `rand` to our dependencies in `Cargo.toml`.
Simple enough. But then, if we launch `cargo build` again:

```
cargo build
  Updating crates.io index
   Locking 15 packages to latest Rust 1.85.0 compatible versions
    Adding rand v0.8.5 (available: v0.9.0)
 Compiling proc-macro2 v1.0.93
 Compiling unicode-ident v1.0.17
 Compiling libc v0.2.170
 Compiling cfg-if v1.0.0
 Compiling byteorder v1.5.0
 Compiling getrandom v0.2.15
 Compiling rand_core v0.6.4
 Compiling quote v1.0.38
 Compiling syn v2.0.98
 Compiling zerocopy-derive v0.7.35
 Compiling zerocopy v0.7.35
 Compiling ppv-lite86 v0.2.20
 Compiling rand_chacha v0.3.1
 Compiling rand v0.8.5
 Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
  Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.48s
```

Woho wait a minute. I have only added one dependency! Just a random
number generator!  Why is it building 15 packages now? Where does all
of this come from? Surely these are not dependencies dragged in by
the `rand` crate, *right?*

Well, apparently they are. If we want to generate a random number, we
need 15 external packages. I would imagine this makes Rust completely
unusable in a professional setting, because nobody would want to audit
15 separate crates just to include a random number generator. And no
professional programmer would include dependencies in a serious project
without first auditing them, *right?* *RIGHT?!*

I mean, each dependency introduces an extra liability in your project;
it is code that you can't control and you never know when it is going to
break. And this is why serious programmers, select dependencies carefully
and only use them when absolutely necessary... *right?*

Ahah, of course they do not. Remember the
[letf-pad incident](https://en.wikipedia.org/wiki/Npm_left-pad_incident)?
Apparently Cargo is of the same breed as npm. And then we wonder why
the software industry is such a shitshow. *Just keep building on top
of the house of cards, man. It's going to be fine, man, don't bother
implementing low-level stuff, that's hard. Just trust random people on
the internet and ship their code, man.*

Bleah.

## The Rust language

So far I talked mostly about the tooling around Rust, but I said nothing
about the language itself.  I want to write some code before making a
more informed opinion about it, but the first impression is that it is
really nice!

I love the type system, especially
[enums](https://doc.rust-lang.org/book/ch06-00-enums.html)
and `match`. I like that this and stuff like `Option<T>` are
first-class citizens; you can do something similar in C++ with
[`std::variant`](https://doc.rust-lang.org/book/ch06-00-enums.html) and
[`std::optional`](https://en.cppreference.com/w/cpp/utility/optional.html),
but the syntax quickly gets messy. I guess this shows the advantage of
making a new language from scratch instead of being forced to live with
decades-old syntax for backwards compatibility.

I especially like this mechanism - Rust's enums, or `std::variant`, or
tagged unions, whatever you like to call them - for error handling. I find
them a better solution than exception, because they enforce correctness:
if your function can fail, your coding must handle it; you can't just
let an error message bubble up from the depths of Hell, wreak havoc in
your control flow and face the user with an "Object reference not set
to an instance of an object".  I think it is great that Rust endorses
this more thorough way of error handling from the start.

On the less-nice side of things, apparently
[integer overflow](https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow)
is still an issue. Eh. At least when compiling in debug mode overflows
are caught, which is nice. But in release mode the program is
going to "panic", which I was not expecting. I mistakenly thought
this was one of the issues that Rust was solving at compile time,
or maybe even at the level of language specification.

This brings me to another problem that I thought Rust would solve,
but it does not: accessing a out-of-bound index of an array also leads
to a panic. I was expecting "don't allow indexes out of bound" to be
included in Rust's compile-time checks, somehow. For example in Ada you
can declare an array to accept only values of a specific
[range type](https://en.wikibooks.org/wiki/Ada_Programming/Types/range),
so that out-of-bound errors are completely eliminated. Apparently a
"panic" is memory safe behavior, but it is definitely not *correct*
behavior.  I guess this was a big misunderstanding from my side: memory
*safety* does not mean memory *correctness* - Rust still allows you to
make mistakes related to memory.

## Documentation

A quick note on the documentation: it is very nice. The book is well
written, and I am enjoying reading through it, even though it is very
basic for me. It is also available offline - at least when installing
rust via `rustup` - which is something I always appreciate.

The compiler error messages, which I consider to be part of the
documentation as well, are simply amazing. Not only they are usually very
precise, not only they often suggest a fix, but they also point you out to
some piece of documentation so that you can learn why your code is wrong.
For example, if you try to compile this code with `rustc filename.rs`:

```
fn main() {
    println("Hello, world!");
}
```

You get:

```
error[E0423]: expected function, found macro `println`
 --> hello.rs:2:2
  |
2 |     println("Hello, world!");
  |     ^^^^^^^ not a function
  |
help: use `!` to invoke the macro
  |
2 |     println!("Hello, world!");
  |            +

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0423`.
```

And if you run `rustc --explain E0423` as suggested:

```
An identifier was used like a function name or a value was expected and the identifier exists but it belongs to a different namespace.

Erroneous code example:

struct Foo { a: bool };

let f = Foo();
// error: expected function, tuple struct or tuple variant, found `Foo`
// `Foo` is a struct name, but this expression uses it like a function name

Please verify you didn't misspell the name of what you actually wanted to use here. Example:

fn Foo() -> u32 { 0 }

let f = Foo(); // ok!

It is common to forget the trailing ! on macro invocations, which would also yield this error:

println("");
// error: expected function, tuple struct or tuple variant,
// found macro `println`
// did you mean `println!(...)`? (notice the trailing `!`)

Another case where this error is emitted is when a value is expected, but something else is found:

pub mod a {
    pub const I: i32 = 1;
}

fn h1() -> i32 {
    a.I
    //~^ ERROR expected value, found module `a`
    // did you mean `a::I`?
}
```

I would not be surprised if the main reason why Rustaceans are so
enthusiastic about the language was actually how nice `rustc` is.
I expect working with this tool will be very pleasant.

## Moving on!

Apart from the
[culture shock](https://en.wikipedia.org/wiki/Culture_shock) of the
installation process and the dependency management, my first impression
of Rust is quite positive.  But as I said, I am just getting started
and my judgement is very superficial.  I do want to write some small
project in Rust, and I think I'll start from re-writing a simple
[math library for modular arithmetic](../2025-01-21-taming-cpp-templates/#constraints-and-concepts)
that I wrote in C++ some time ago.

Stay tuned for more 🦀