Anton Zhiyanov
@antonz.org
Open source maintainer at https://github.com/nalgeon. Author & educator at https://antonz.org
Pinned
Anton Zhiyanov
@antonz.org
· Dec 12
Gist of Go: Concurrency is out!
Learn Go concurrency from the ground up with 50 auto-tested exercises and tons of interactive examples.
It's a full course + book in one.
antonz.org/go-concurrency
Learn Go concurrency from the ground up with 50 auto-tested exercises and tons of interactive examples.
It's a full course + book in one.
antonz.org/go-concurrency
Based on the conversation, this one will probably get rejected too. I also don't think it's a good idea to add UUID string (!) generation methods to crypto/rand.
January 11, 2026 at 3:57 PM
Based on the conversation, this one will probably get rejected too. I also don't think it's a good idea to add UUID string (!) generation methods to crypto/rand.
Very interesting, thank you! It's definitely hard to see all these nuances from the outside, being just a SIMD bystander.
January 11, 2026 at 3:53 PM
Very interesting, thank you! It's definitely hard to see all these nuances from the outside, being just a SIMD bystander.
Oh wow, another one :) I think I've seen several of these get rejected.
January 11, 2026 at 3:42 PM
Oh wow, another one :) I think I've seen several of these get rejected.
The invention of the X-ray permanently changed medicine.
But was it wise to use X-rays for entertainment, shopping, and beauty treatments? Not really.
AI skepticism (not luddism) is the healthiest attitude for now.
But was it wise to use X-rays for entertainment, shopping, and beauty treatments? Not really.
AI skepticism (not luddism) is the healthiest attitude for now.
January 11, 2026 at 3:03 PM
The invention of the X-ray permanently changed medicine.
But was it wise to use X-rays for entertainment, shopping, and beauty treatments? Not really.
AI skepticism (not luddism) is the healthiest attitude for now.
But was it wise to use X-rays for entertainment, shopping, and beauty treatments? Not really.
AI skepticism (not luddism) is the healthiest attitude for now.
Yeah, my bad. Thanks!
I was a bit confused because the author talks about finding transitive dependencies in the article (at the graph level, not in the source data), but then moves on to the final statistics without including them.
Well, it must be bcrypt then! Everyone loves bcrypt, right? :)
I was a bit confused because the author talks about finding transitive dependencies in the article (at the graph level, not in the source data), but then moves on to the final statistics without including them.
Well, it must be bcrypt then! Everyone loves bcrypt, right? :)
January 11, 2026 at 2:18 PM
Yeah, my bad. Thanks!
I was a bit confused because the author talks about finding transitive dependencies in the article (at the graph level, not in the source data), but then moves on to the final statistics without including them.
Well, it must be bcrypt then! Everyone loves bcrypt, right? :)
I was a bit confused because the author talks about finding transitive dependencies in the article (at the graph level, not in the source data), but then moves on to the final statistics without including them.
Well, it must be bcrypt then! Everyone loves bcrypt, right? :)
They are probably transitive dependencies of other high-profile third-party packages like Gin.
January 11, 2026 at 1:22 PM
They are probably transitive dependencies of other high-profile third-party packages like Gin.
Thanks :) I also tried building fake simd/amd64 and simd/arm64 myself. I like this setup better than having just one simd/archsimd package, but after trying both, I think either option works.
I'm definitely not a fan of the "package per vector size" approach 😅
I'm definitely not a fan of the "package per vector size" approach 😅
January 11, 2026 at 1:15 PM
Thanks :) I also tried building fake simd/amd64 and simd/arm64 myself. I like this setup better than having just one simd/archsimd package, but after trying both, I think either option works.
I'm definitely not a fan of the "package per vector size" approach 😅
I'm definitely not a fan of the "package per vector size" approach 😅
January 11, 2026 at 12:44 PM
So the second most imported 3rd-party dependency is Google's own UUID package. I wonder what it would take to convince the Go team to add it to stdlib.
Also, I don't think x/crypto and x/net should be here at all. Both are imported by stdlib itself, so they're basically included in every project.
Also, I don't think x/crypto and x/net should be here at all. Both are imported by stdlib itself, so they're basically included in every project.
January 11, 2026 at 12:44 PM
So the second most imported 3rd-party dependency is Google's own UUID package. I wonder what it would take to convince the Go team to add it to stdlib.
Also, I don't think x/crypto and x/net should be here at all. Both are imported by stdlib itself, so they're basically included in every project.
Also, I don't think x/crypto and x/net should be here at all. Both are imported by stdlib itself, so they're basically included in every project.
Yes, this is more verbose than just having a single simd/archsimd with conditional logic in the client code to pick the right type.
But to me, this seems clearer and easier to maintain.
But to me, this seems clearer and easier to maintain.
January 11, 2026 at 12:04 PM
Yes, this is more verbose than just having a single simd/archsimd with conditional logic in the client code to pick the right type.
But to me, this seems clearer and easier to maintain.
But to me, this seems clearer and easier to maintain.
My idea was to have simd/amd64 and simd/arm64 with distinct types, each package reflecting the CPU architecture (AVX/Neon) without even trying to be portable.
Then the user would create, for example, an Add function with two different implementations governed by build tags.
Then the user would create, for example, an Add function with two different implementations governed by build tags.
January 11, 2026 at 12:02 PM
My idea was to have simd/amd64 and simd/arm64 with distinct types, each package reflecting the CPU architecture (AVX/Neon) without even trying to be portable.
Then the user would create, for example, an Add function with two different implementations governed by build tags.
Then the user would create, for example, an Add function with two different implementations governed by build tags.
The phrase "vector types will be defined on the architectures that support them" is what I'm talking about.
I interpret it as "some archsimd types will be available on amd64 and some on arm64."
In my opinion, this is less clear than having separate packages with partly overlapping type sets.
I interpret it as "some archsimd types will be available on amd64 and some on arm64."
In my opinion, this is less clear than having separate packages with partly overlapping type sets.
January 10, 2026 at 8:36 PM
The phrase "vector types will be defined on the architectures that support them" is what I'm talking about.
I interpret it as "some archsimd types will be available on amd64 and some on arm64."
In my opinion, this is less clear than having separate packages with partly overlapping type sets.
I interpret it as "some archsimd types will be available on amd64 and some on arm64."
In my opinion, this is less clear than having separate packages with partly overlapping type sets.
Yes, the methods map to AVX instructions very closely.
January 9, 2026 at 5:47 PM
Yes, the methods map to AVX instructions very closely.
What happens when Go adds support for SIMD on arm64? Wouldn't simd/archsimd become a messy bag of types, some supported only on amd64 and others only on arm64?
January 9, 2026 at 11:24 AM
What happens when Go adds support for SIMD on arm64? Wouldn't simd/archsimd become a messy bag of types, some supported only on amd64 and others only on arm64?
I think it's a great idea to let developers try things out and give feedback before designing a high-level interface.
But there's one thing I don't quite understand.
Why is the package called simd/archsimd? Since it's amd64-specific, shouldn't it be simd/amd64 or maybe simd/avx?
But there's one thing I don't quite understand.
Why is the package called simd/archsimd? Since it's amd64-specific, shouldn't it be simd/amd64 or maybe simd/avx?
January 9, 2026 at 11:24 AM
I think it's a great idea to let developers try things out and give feedback before designing a high-level interface.
But there's one thing I don't quite understand.
Why is the package called simd/archsimd? Since it's amd64-specific, shouldn't it be simd/amd64 or maybe simd/avx?
But there's one thing I don't quite understand.
Why is the package called simd/archsimd? Since it's amd64-specific, shouldn't it be simd/amd64 or maybe simd/avx?
Go 1.26 brings the long-awaited vectorized operations (SIMD) in the simd/archsimd package.
Since it's hard to create a portable high-level API, the Go team decided to start with a low-level, architecture-specific one and support only amd64 for now.
Since it's hard to create a portable high-level API, the Go team decided to start with a low-level, architecture-specific one and support only amd64 for now.
January 9, 2026 at 11:24 AM
Go 1.26 brings the long-awaited vectorized operations (SIMD) in the simd/archsimd package.
Since it's hard to create a portable high-level API, the Go team decided to start with a low-level, architecture-specific one and support only amd64 for now.
Since it's hard to create a portable high-level API, the Go team decided to start with a low-level, architecture-specific one and support only amd64 for now.
I think it's typically the author who uses AI to produce documentation for their own undocumented code. Hopefully, the author knows their own intentions :) and reviews the generated docs, of course.
January 8, 2026 at 12:51 PM
I think it's typically the author who uses AI to produce documentation for their own undocumented code. Hopefully, the author knows their own intentions :) and reviews the generated docs, of course.
A typical use case is a generic type that supports operations with arguments or results of the same type as itself (like Ordered[T]).
We can use such a type as a member in a generic container (like Tree[T Ordered[T]] — see the screenshot).
This makes Go's generics a bit more expressive.
We can use such a type as a member in a generic container (like Tree[T Ordered[T]] — see the screenshot).
This makes Go's generics a bit more expressive.
January 8, 2026 at 12:46 PM
A typical use case is a generic type that supports operations with arguments or results of the same type as itself (like Ordered[T]).
We can use such a type as a member in a generic container (like Tree[T Ordered[T]] — see the screenshot).
This makes Go's generics a bit more expressive.
We can use such a type as a member in a generic container (like Tree[T Ordered[T]] — see the screenshot).
This makes Go's generics a bit more expressive.
For example, this interface declaration:
type Ordered[T Ordered[T]] interface {
Less(T) bool
}
resulted in a compile error: "invalid recursive type: Ordered refers to itself".
With Go 1.26, it compiles just fine.
↓
type Ordered[T Ordered[T]] interface {
Less(T) bool
}
resulted in a compile error: "invalid recursive type: Ordered refers to itself".
With Go 1.26, it compiles just fine.
↓
January 8, 2026 at 12:46 PM
For example, this interface declaration:
type Ordered[T Ordered[T]] interface {
Less(T) bool
}
resulted in a compile error: "invalid recursive type: Ordered refers to itself".
With Go 1.26, it compiles just fine.
↓
type Ordered[T Ordered[T]] interface {
Less(T) bool
}
resulted in a compile error: "invalid recursive type: Ordered refers to itself".
With Go 1.26, it compiles just fine.
↓
Go 1.26 received a somewhat under-the-radar language change: recursive type constraints in generics.
Previously, type constraints couldn't directly or indirectly refer to type parameters.
↓
Previously, type constraints couldn't directly or indirectly refer to type parameters.
↓
January 8, 2026 at 12:46 PM
Go 1.26 received a somewhat under-the-radar language change: recursive type constraints in generics.
Previously, type constraints couldn't directly or indirectly refer to type parameters.
↓
Previously, type constraints couldn't directly or indirectly refer to type parameters.
↓
Thank you! Commit descriptions in the Go project are usually high quality, but yours are on another level.
It's like you've thought about all possible questions the reader might have and answered them in advance.
A pleasure to read!
It's like you've thought about all possible questions the reader might have and answered them in advance.
A pleasure to read!
January 7, 2026 at 12:35 AM
Thank you! Commit descriptions in the Go project are usually high quality, but yours are on another level.
It's like you've thought about all possible questions the reader might have and answered them in advance.
A pleasure to read!
It's like you've thought about all possible questions the reader might have and answered them in advance.
A pleasure to read!
Thanks again for taking the time to explain and for making the heap size example!
January 6, 2026 at 8:14 PM
Thanks again for taking the time to explain and for making the heap size example!
Having len == cap would guarantee, for example, that any attempt to append to the slice would allocate a new backing array instead of changing the existing one.
But after reading your explanation, I don't really see this property could be useful :)
But after reading your explanation, I don't really see this property could be useful :)
January 6, 2026 at 8:14 PM
Having len == cap would guarantee, for example, that any attempt to append to the slice would allocate a new backing array instead of changing the existing one.
But after reading your explanation, I don't really see this property could be useful :)
But after reading your explanation, I don't really see this property could be useful :)
Thank you very much for the detailed answer!
Yes, I understand that both options allocate the same backing array.
I thought that by "perfectly sized" you meant creating a slice where len = cap = finalSize.
Yes, I understand that both options allocate the same backing array.
I thought that by "perfectly sized" you meant creating a slice where len = cap = finalSize.
January 6, 2026 at 8:14 PM
Thank you very much for the detailed answer!
Yes, I understand that both options allocate the same backing array.
I thought that by "perfectly sized" you meant creating a slice where len = cap = finalSize.
Yes, I understand that both options allocate the same backing array.
I thought that by "perfectly sized" you meant creating a slice where len = cap = finalSize.
Hey @thepudds.bsky.social! Thanks for io.ReadAll in Go 1.26 :)
Why did you choose to use append-make instead of just make for the final slice?
Using append-make sets the slice capacity to the next size class, which seems to go against the idea of having a "perfectly-sized slice", doesn't it?
Why did you choose to use append-make instead of just make for the final slice?
Using append-make sets the slice capacity to the next size class, which seems to go against the idea of having a "perfectly-sized slice", doesn't it?
January 6, 2026 at 2:44 PM
Hey @thepudds.bsky.social! Thanks for io.ReadAll in Go 1.26 :)
Why did you choose to use append-make instead of just make for the final slice?
Using append-make sets the slice capacity to the next size class, which seems to go against the idea of having a "perfectly-sized slice", doesn't it?
Why did you choose to use append-make instead of just make for the final slice?
Using append-make sets the slice capacity to the next size class, which seems to go against the idea of having a "perfectly-sized slice", doesn't it?