Just use it when it is needed. Try don't use it when it is unnecessary.
871 karma · joined February 7, 2015
The article's points feel overly simplistic/shallow and lack the depth you'd expect from an experienced Go programmer.
This is indeed a point which makes Zig inflexible.
It is pity that Go generics designer never expressed the intention to unify custom generics and built-in generics.
Even worse, it was also promoted to keep backboard-compatibility seriously. But Go 1.22 broke the backward-compatibility so badly ([3] [1]). Despite this, the Go 1.22 release notes still claims "As always, the release maintains the Go 1 promise of compatibility".
[1]: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
[2]: https://go101.org/blog/2025-03-15-some-facts-about-iterators...
[3]: https://go101.org/bugs/go-build-directive-not-work.html
And the change makers even have no interests to fix the problems caused by the changes:
* https://github.com/golang/go/issues/66070#issuecomment-19816...
* https://github.com/golang/go/issues/71830
* https://github.com/spq/pkappa2/issues/238
No, this is not true for Go, at least for the current Go generics.
At runtime, Go generics can't be faster than generated repetitive code. Often, generic code is a little slower. Because sometimes values of type parameters are treated as interface values by the Go compiler, even if they are not.
> Handling interface{} was just painful.
Go generics are often helpless for this. Most use cases of interface{} are for reflection purpose and can't be re-implemented by Go generics. Some non-reflection use cases can't be also re-implemented by Go generics, because Go generics don't support type unions.
Disagree. IMHO, this idea is the root cause of why Go generics is so complicate but also restrictive at the same time. And it introduces significant challenges in implementation and design: https://go101.org/generics/888-the-status-quo-of-go-custom-g...
Does it has a stable c API?
BTW, I haven't found an AI system can get the correct output for the following Go code:
package main
import "fmt"
func main() {
for counter, n := 0, 2; n >= 0; n-- {
defer func(v int) {
fmt.Print("#", counter, ": ", v, "\n")
counter++
}(n)
}
} package main
func alwaysFalse() bool {
return false
}
func main() {
switch alwaysFalse() // don't format the code
{
case true:
println("true")
case false:
println("false")
}
}
Not true for Go 1.22 toolchains. When you use Go 1.21-, 1.22 and 1.23+ toolchains to build the following Go code, the outputs are not consistent:
//go:build go1.21
package main
import "fmt"
func main() {
for counter, n := 0, 2; n >= 0; n-- {
defer func(v int) {
fmt.Print("#", counter, ": ", v, "\n")
counter++
}(n)
}
}btw, README says Go 1.17+ is required, but go.mod says 1.23+.
I agree that Zig will not become very popular. It needs certain programming experiences to master it. But I'm quite sure it will become more popular than Rust.
And Zig is better when integrating with C/C++ libraries.