Alex Rios
Alex Rios
@alexrios.me
Former Carioca 🏖 living in Curitiba 🏔 ⛩️ Supreme Leader ⛩️ Author of System Programming Essentials with Go & Learning Zig. Posts about Tech Leadership, Go and Zig. He/Him
75 followers21 following217 posts
I wrote about a problem many engineering organizations know all too well, but few are willing to recognize in themselves. alexriosme.substack.com/p/the-princi...
Go spins in both of its mutexes, but there's no sync.SpinMutex. Why? My GopherCon Africa talk, now a 4-part series: alexrios.me/blog/go-spin...
Atualizei o material sobre Go Modules em português até o Go 1.27 💚 Saímos do GitBook e ganhamos casa nova: gomodules.alexrios.me Exemplos revisados e contribuições abertas. Material em português merece circular 🇧🇷
Alex Rios reposted
Simplicity gets agreed and then broken by a flag added for one caller. Hard caps beat intentions, because the linter doesn't get tired at 5pm. Tenets don't stop the deadline, but a cap the build enforces does. prickles.org/tenet/simpli...
I updated slogbox for Go 1.27 and JSON v2. I wrote about the migration decisions: what to preserve in the JSON output and how to handle errors after part of an HTTP response has already been sent. alexrios.me/blog/slogbox...
Atualizei o slogbox para Go 1.27 e JSON v2. Escrevi sobre as decisões da migração: o que preservar no JSON e como lidar com erros quando parte da resposta HTTP já foi enviada. alexrios.me/blog/slogbox...
Hey Gophers, I need your help! What theme should I send to @gophercon.jp call for papers? I have only 2 submissions! Don't say Green Tea GC internals. It's the first one 🤓.
A module can look encapsulated while another reaches straight into its state. I wrote about transparent boundaries, with a Go example that moves mutation back to its owner. alexrios.me/blog/patholo...
Continuando os posts sobre aspectos fundamentais de design 🌞 Nesse post, exploro as "fronteiras transparentes". alexrios.me/blog/patholo...
Seguindo a série sobre fundamentos de design de software: flags booleanas e estados que não deveriam existir. alexrios.me/blog/bool-fl...
Continuing my posts on software design fundamentals, this time I’m looking at boolean flags and states our types should not allow.
In the post, I connect this to product and sum types, then work through a small Go implementation. I also cover zero values, parsing external data, and why valid states do not guarantee valid transitions. alexrios.me/blog/bool-fl...
Not only me! We have a lot of amazing speakers this year: @alexdaubois.bsky.social @goinggo.net @danicat83.bsky.social @mvdan.cc @dario.cat @davideimola.dev @jespino.bsky.social @empijei.bsky.social l @deadprogram.com
My slides from GopherCon LATAM 2026 are now available: 🇧🇷 PT-BR talks.alexrios.me/gc-latam-26-... 🇪🇸 ES talks.alexrios.me/gc-latam-26-... 🌎 EN talks.alexrios.me/gc-latam-26-... Hope they’re useful even if you couldn’t make it to the talk.
Alex Rios reposted
Great talk from @alexrios.me on spin locks in Go at GopherCon Latam. They can outperform sync.Mutex, but only under a narrow set of conditions: a critical section under 100 ns, proven contention, multi-core deployment, and why Go generally favors safety, portability, and fairness over exposing them.
Most Go design problems don't start with architecture. They start with a function accepting more than it needs. I shared thoughts about precise signatures, small interfaces, and why every parameter should be an honest contract. alexrios.me/blog/stamp-c...
O problema é quando organizar o trabalho vira substituto para melhorar o trabalho.
Times raramente pulam design porque não se importam. Pulam porque design parece custoso hoje, enquanto fazem debugging, retrabalho e dor operacional chegam aos poucos durante os próximos dezoito meses. Essa troca quase sempre sai cara 😅 .
Cortar design aumenta o custo total de um projeto, como a cultura do MVP continua empurrando times pro lado mais caro da curva. Além disso, um pouco de o que “suficiente design” significa na prática. alexrios.me/blog/underbu...
Teams rarely skip design because they do not care. They skip it because design looks expensive today, while debugging, rework, and operational pain arrive quietly over the next eighteen months. That trade is usually a bad one.
I wrote about why underbudgeting design increases a project's total cost, why "MVP culture" keeps choosing the expensive side of the curve, and what “enough design” looks like in practice. alexrios.me/blog/underbu...
"Should this be a constant or a config value?" "Should we use DI here or construct it inline?" Same question, dressed up: when does this identifier get its final value?
I wrote about the five binding times, named by what each one actually costs to change. From "a code change in every copy" down to "a provider update". alexrios.me/blog/late-bi...
We often call something a “heuristic” when, in practice, it’s just a way to avoid understanding the problem. When a solution starts accumulating exceptions, weights, thresholds, and special rules, maybe the problem isn’t the algorithm. Maybe it’s the structure we chose to represent the problem.