Sujet : go
-
Choisir Go ou Rust pour un nouveau service : une procédure de décision sans benchmarks
Choisir entre Go et Rust pour un service à partir des propriétés documentées des langages et des contraintes de l’équipe plutôt que d’idées reçues sur les benchmarks : gestion de la mémoire, traitement des erreurs et concurrence, profil de la charge, bibliothèques nécessaires et personnes qui assureront la maintenance dans deux ans.
-
Cancellation and deadlines in Go with context.Context
Thread a context.Context from the incoming request through every call that can block, derive child contexts with WithTimeout or WithCancel, always call the cancel function, and check ctx.Done() in loops so that a client disconnect or a deadline stops the whole tree of goroutines instead of leaving them running.
-
Go interfaces: implicit satisfaction and the non-nil nil
A Go type satisfies an interface by having its methods; nothing is declared. That makes small interfaces at the point of use cheap, but an interface value is a pair of type and value, so a nil pointer stored in an error interface is not equal to nil.
-
Go error handling: wrapping with %w, errors.Is and errors.As
Go functions return errors as ordinary values; add context with fmt.Errorf and the %w verb so the original stays reachable, then test the chain with errors.Is for sentinel values and errors.As (or the generic errors.AsType) for types, instead of comparing strings or using ==.
-
Goroutines, channels and the sync package: Go concurrency in outline
A go statement runs a function call concurrently on a cheap, growable stack; channels move values between goroutines and block until both sides are ready; sync.WaitGroup, Mutex and Once cover the cases where sharing memory is simpler. A data race is a bug whose outcome the memory model only partly constrains, and the -race detector is the tool for finding it.
-
How much longer does it take an engineer from a dynamic language to become productive in Rust than in Go, and which concepts account for the gap?
Open question: Go is often described as quick to pick up and Rust as demanding, and the 2024 State of Rust survey reports that around 31% of non-users cite perceived difficulty; but few sources measure time to a first merged change, time to unsupervised code review, or which concepts (ownership, lifetimes, async, traits) consume that time for engineers arriving from Python, Ruby or JavaScript.
-
Table-driven tests in Go with subtests
Write one test function that iterates over a slice of named cases and runs each with t.Run; the cases become data, a single case can be selected with go test -run 'TestX/name', and t.Parallel, t.Helper and t.Cleanup keep the loop fast and readable.
-
Rust traits versus Go interfaces: explicit impl, implicit satisfaction
Both languages abstract over behaviour without class hierarchies, but a Go type satisfies an interface by merely having the methods, while a Rust type implements a trait only through an explicit impl block subject to the orphan rule; Rust additionally separates compile-time generics (monomorphised) from dyn trait objects (dynamic dispatch), a choice Go makes for the programmer.
-
Go modules: go.mod, go.sum and the major version suffix
A Go module is a versioned tree of packages described by go.mod; the go command picks dependency versions with minimal version selection, verifies downloads against go.sum, and requires a /v2-style suffix in the module path for every major version above 1, so incompatible versions have different import paths.
Lisible par machine : JSON