Despite its relative youth, Rust already has an ecosystem large enough that it’s
hard to keep track of everything that’s available. If you know what you want, you
may be able a number of other calling conventions that you supply as a string
following the extern keyword (in both fn and block context). For example, extern
"system" says to use the calling convention of the operating system’s standard
library interface, which at the time of writing is the same as "C" everywhere
except on Win32, which uses the "stdcall" calling convention. In general, you’ll
rarely need to supply a calling convention explicitly unless you’re working with
particularly platform-specific or highly optimized external interfaces, so just
extern (which is extern "C") will be fine.
Note
A function’s calling convention is part of its type. That is, the type extern "C"
fn() is not the same as fn() (or extern "Rust" fn()), which is different again from
extern "system" fn().
Other Binary Artifacts
Normally, you compile Rust code only to run its tests or build a binary that you’re
then going to distribute or run. Unlike in many other languages, you don’t
generally compile a Rust library to distribute it to others—if you run a command
like cargo publish, it just wraps up your crate’s source code and uploads it to
crates.io. This is mostly because it is difficult to distribute generic code as
anything but source code. Since the compiler monomorphizes each generic function to
the provided type arguments, and those types may be defined in the caller’s crate,
the compiler must have access to the function’s generic form, which means no
optimized machine code!
Technically speaking, Rust does compile binary library artifacts, called rlibs, of
each dependency that it combines in the end. These rlibs include the information
necessary to resolve generic types, but they are specific to the exact compiler
used and can’t generally be distributed in any meaningful way.
So what do you do if you want to write a library in Rust that you then want to
interface with from another programming language? The solution is to produce C-
compatible library files in the form of dynamically linked libraries (.so files on
Unix, .dylib files on macOS, and .dll files on Windows) and statically linked
libraries (.a files on Unix/macOS and .lib files on Windows). Those files look like
files produced by C code, so they can also be used by other languages that know how
to interact with C.
To produce these C-compatible binary artifacts, you set the crate-type field of the
[lib] section of your Cargo.toml file. The field takes an array of values, which
would normally just be "lib" to indicate a standard Rust library (an rlib)to search
your way to a set of appropriate crates and then use download statistics and
superficial vibe-checks on each crate’s repository to determine which may make for
reasonable dependencies. However, there’s also a plethora of tools, crates, and
general language features that you might not necessarily know to look for that
could potentially save you countless hours and difficult design decisions.
In this section, I’ll go through some of the tools, libraries, and Rust features I
have found helpful over the years in the hopes that they may come in useful for you
at some point too!
Tools
First off, here are some Rust tools I find myself using regularly that you should
add to your toolbelt:
cargo-deny
Provides a way to lint your dependency graph. At the time of writing, you can use
cargo-deny to allow only certain licenses, deny-list crates or specific crate
versions, detect dependencies with known vulnerabilities or that use Git sources,
and detect crates that appear multiple times with different versions in the
dependency graph. By the time you’re reading this, there may be even more handy
lints in place.
cargo-expand
Expands macros in a given crate and lets you inspect the output, which makes it
much easier to spot mistakes deep down in macro transcribers or procedural macros.
cargo-expand is an invaluable tool when you’re writing your own macros.
cargo-hack
Helps you check that your crate works with any combination of features enabled. The
tool presents an interface similar to that of Cargo itself (like cargo check,
build, and test) but gives you the ability to run a given command with all possible
combinations (the powerset) of the crate’s features.
