Rust

C char * is powerful and vague.

It may mean mutable bytes, a NUL-terminated string, ASCII text, or simply the argument type required by a C API. The caller also has to know who frees the memory, whether it contains \0, what encoding it uses, and where the length comes from.

Rust does not put all of that into one type. It splits the common cases:

one byte: u8
bytes: &[u8] / Vec<u8>
UTF-8 text view: &str
owned UTF-8 text: String
C string view: &CStr
owned C string: CString

This article builds the first boundary: bytes, text, and C strings are different things.

In C, a binary buffer is often represented as pointer plus length:

int parse_packet(const uint8_t *buf, size_t len);

This pattern is flexible, but it carries risk. Whether buf may be null, whether len is trustworthy, whether the function mutates data, whether it stores the pointer, and when the caller may free memory are all conventions outside the type.

Rust does not remove this pattern. It splits it into more precise types:

read-only view: &[u8]
writable view: &mut [u8]
owned buffer: Vec<u8>
fixed array: [u8; N]

This article is only about binary buffers. Strings, String, and &str come later.

For a C developer writing Rust for the first time, the unfamiliar part is often not if, for, or function calls. The first real difference is the engineering entry point: C programs often begin with main.c, gcc, Makefiles, and argc/argv; Rust programs usually begin inside a Cargo project.

That is not just a tooling difference. Cargo manages source layout, dependencies, builds, tests, and package metadata. main also becomes more than a function returning an integer: error handling, standard output, standard error, and exit status enter the program structure early.