Primitive Scalars: Go vs Rust
Go's int grows with the architecture; Rust fixes sizes like i32 at compile time. Use Go's int for loops and Rust's i32 for counters, but both require explicit casts to mix. Assuming Go's int is 64-bit breaks 32-bit builds, and Rust's as truncates silently.
Why it exists
Processors only understand fixed register widths, but programmers want portable code. Go hides this by providing int and uint that match the native word size, reducing decision fatigue. Rust exposes the hardware truth by making every scalar width explicit, preventing assumptions about memory layout from leaking across platforms.
The mental model
Think of Go's scalars as defaults that just work on whatever machine compiles them. int is big enough to count memory on the local CPU, and conversions between numeric types are explicit but constants are flexible. Rust's scalars are precision tools: i32 is exactly four bytes everywhere, and the compiler treats mixing a u16 with an i32 as a type error rather than a silent conversion.
How it works
Go offers bool, int, uint, uintptr, and explicit widths like int8 through int64, uint8 through uint64, plus float32, float64, and complex numbers. int and uint are either 32 or 64 bits depending on the architecture. Rust offers bool, char, i8 through i128, u8 through u128, isize, usize, f32, and f64. isize and usize match the pointer width, but idiomatic Rust avoids them for general math. Go allows untyped constants to morph into whatever width fits, while Rust demands every literal have a known type or a suffix like 42u32.
When to use it
Use Go's int for indexing, counters, and slice lengths where the platform word is natural. Use Go's fixed-width types only when you need guaranteed layout for wire formats or C interop. In Rust, use i32 as the default integer, u8 for raw bytes, and usize exclusively for indexing and collection lengths. Use f64 in both languages unless you are optimizing for memory or GPU bandwidth.
When not to use it
Do not store Go's int in a database column or binary protocol if the width must be stable across 32-bit and 64-bit builds, because its size changes silently. Do not use Rust's as keyword for numeric conversions when correctness matters, because it truncates and wraps without panic; prefer TryFrom or checked arithmetic instead. Avoid Rust's isize for file sizes or network counts, because it can be 32 bits on some targets.
One canonical example
Imagine writing a binary file header that starts with a 32-bit magic number and a 16-bit version. In Go, you must use uint32 and uint16 fields in your struct; if you used int, a 64-bit build would write eight bytes for the first field and corrupt the format. In Rust, you naturally define the struct with u32 and u16 fields, and the compiler guarantees the layout matches your intent on every target without hidden platform variation.
Interview question
What are the risks of using Go's int for a fixed 32-bit binary field and Rust's as to cast u32 to u16?
- a.Go's int is safe because its constants auto-adjust to the target width, and Rust's as refuses narrowing conversions.
- b.Go's int automatically truncates to 32 bits at runtime; Rust's as panics if the value overflows.
- c.Go's int may write 64 bits on some architectures, corrupting the format; Rust's as silently truncates the value.Correct
- d.Go requires explicit casts between int and int32, preventing this bug; Rust's as always zero-extends without data loss.
Why? this is the answer
Go's int matches the architecture word size, so a 64-bit build writes eight bytes and corrupts a fixed-layout format, while Rust's as truncates without warning. Option D is tempting because Go does require explicit casts between types, but that does not stop an int struct field from having a platform-dependent width.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on go — each one lists the topics its interview covers.
See open roles