How do Go and Rust control visibility of functions and types?

WHAT THIS TESTS: This question tests your grasp of encapsulation in compiled systems languages and your ability to compare convention-driven versus explicit-keyword language design. Interviewers want to hear that both languages enforce visibility statically, but they differ in syntax granularity and default scope: Go at the package level and Rust at the module level.

A GOOD ANSWER COVERS: First, state Go's rule: capitalization determines export status. An identifier starting with an uppercase letter is exported and visible to other packages; lowercase means unexported and package-private. The compiler enforces this with no extra keywords. Second, state Rust's rule: the pub keyword controls visibility explicitly. Without pub, an item is private to its module. Rust also provides finer controls such as pub(crate) for crate-wide visibility and pub(super) for parent-module visibility. Third, contrast the design philosophies. Go favors immediate visual cues at the call site and minimal syntax, while Rust favors explicit opt-in and fine-grained control over API surfaces. Fourth, clarify that both checks happen at compile time and are rigid, not advisory.

COMMON WRONG ANSWERS: Claiming Go uses public or private keywords or file-level scoping. Saying Rust defaults to public visibility. Asserting either language has protected or friend access levels like C++ or Java. Stating that Go exported names are visible only within the same file, or that Rust pub makes something globally visible regardless of module hierarchy. Suggesting visibility is optional, runtime-enforced, or easily bypassed.

LIKELY FOLLOW-UPS: How do you limit API surface area in a large Go package when unexported names are visible to the whole package? When would you use pub(crate) versus pub in a Rust library? How do Go interfaces interact with exported and unexported types? Can reflection access unexported fields in Go, and what are the implications? How does Rust's module system differ from Go's package system in terms of code organization?

ONE CONCRETE EXAMPLE: In Go, if package auth declares type User struct { Name string; secret string }, Name is exported and callable from package main, but secret is package-private. In Rust, if mod auth declares pub struct User { pub name: String, secret: String }, then name is visible to consumers who can reach the auth module, while secret remains module-private and will trigger a compile error if accessed externally.