discussion
There are languages similar to Go, but there is something so unique about it that no one can replicate. It's even hard for me to understand as well. I've tried Elixir, Gleam, Rust, Zig, Odin, Java, Scala, and yet, every time I need to build something that I know needs to be good, fast, and well done Go is the language that I pick.
It could be familiarity, but it's really hard to beat the whole Go environment. I think most of the time engineers evaluate things into a single dimension axis either in terms of performance or type system expressiveness, but good code involves so may aspects and Go does surprisingly well in all of them.
discussion
If you haven't read , it's a must-read.
It shows how you can use the inline analyzer in some clever ways to migrate your APIs. If you are a library author now you can ask your users to run go fix to upgrade to the new APIs.
The gist is that:
-
Let's say you have a function that's superseded by another one.
-
You can call the new function from the old one.
-
And annotate the old function with the
//go:fix inlinedirective.
This way, when you run go fix ./... the modernizer will automatically swap the old implementation with the new one.
// Deprecated: use gensum instead
//
//go:fix inline
func sum(slice []int) int {
return gensum(slice) // calling the new func from the old one
}
func gensum[T Numeric](slice []T) T {
var total T
for _, v := range slice {
total += v
}
return total
}
func main() {
v := []int{1, 2, 3}
- var res int = sum(v) // sum will be replaced with gensum
+ var res int = gensum(v)
fmt.Println(res)
}
I thought that the inline analyzer should be fairly easy to write. Turns out it's . The blog explores why.
I'm curious to see how this influences the broader Go ecosystem when it comes to handling API migration. Really cool stuff.
