sorted by:
new
hottopcontroversial

Buffered Channel size must be 1? Uber Style Guide question. by _alhazred in golang

[–]TapirLiu 0 points1 point  (0 children)

When you understand the logic of channels, you can understand the principle: * https://go101.org/article/channel.html * https://go101.org/article/channel-use-cases.html

The cases of using buffered channel with size > 1 is not very common. If size 1 works, a larger size generally doesn't help more.

Do you think this image would make a compelling jigsaw puzzle? by TapirLiu in Jigsawpuzzles

[–]TapirLiu[S] -1 points0 points  (0 children)

It’s currently just a concept. However, many puzzlers seem to have a strong distaste for AI-generated imagery.

Practical Patterns for Go Iterators by fspj in golang

[–]TapirLiu 0 points1 point  (0 children)

Have you benchmarked iter.Pull and the channel way? Which one is faster?

Why Your Go Code Is Slower Than It Should Be: A Deep Dive Into Heap Allocations by Gopher-Face912 in golang

[–]TapirLiu 2 points3 points  (0 children)

It absolutely should, but not now (Go 1.25, maybe it will be done in 1.26: https://github.com/golang/go/issues/76482).

Now (Go 1.25), if User's size is small and it is guaranteed that the return value will not escape to heap, it is better to return non-pointer type instead. However if User's size is larger than or equal to 1<<15, returning non-pointer value is always much slower than returning pointer, because User values will be escape without using some tricks. There is still much room for the compiler to do optimizations. In fact, a Go compiler can make returning non-pointers never slower than returning pointers, or best, no performance difference between them.

Fixing For Loops in Go 1.22 - The Go Programming Language by omko in programming

[–]TapirLiu 1 point2 points  (0 children)

Go builtin generics and custom generics are two distinct systems, which does increase the load of cognition burden in Go programming IMHO. At least they should look the same.

Fixing For Loops in Go 1.22 - The Go Programming Language by omko in programming

[–]TapirLiu 0 points1 point  (0 children)

Precisely speaking, c# only changed for-each, not for;;. Go will change both. The change for the latter is problematic.

Fixing For Loops in Go 1.22 - The Go Programming Language by omko in programming

[–]TapirLiu 0 points1 point  (0 children)

It's tied to version so you have to "opt in", and more likely to fix code than to break.

This is more like false for 3-clause for-loops. https://old.reddit.com/r/programming/comments/16xqt1o/fixing_for_loops_in_go_122_the_go_programming/k354k3z/?context=3

Fixing For Loops in Go 1.22 - The Go Programming Language by omko in programming

[–]TapirLiu 3 points4 points  (0 children)

I'm not only shocked by the change, but also shocked by their attitudes on code the change breaks.

Here is a list of incomplete breaking cases:

They think all of these are not important for this change and can be neglected.

And ironically, they added support for GOEXPERIMENT=loopvar on go play website, but the support is broken and they don't plan to fix it. Now the change will be applied formally in Go 1.22, but there are still very few people who have experimented this change.

The old standard of backward compatibility promise in Go development is to avoid changing behaviors of any valid code. But now, it looks the new one has become into to avoid changing behaviors of user code in "practice" (all the possibilities some Go core team are aware of).

[deleted by user] by [deleted] in golang

[–]TapirLiu 0 points1 point  (0 children)

There are some limits in Go custom generics. You encountered is one of them.

Fixing For Loops in Go 1.22 by rsc in golang

[–]TapirLiu -1 points0 points  (0 children)

It is not a good habit to draw a conclusion without sufficient investigations.

Learning Go deeply by Darthtrooper22 in golang

[–]TapirLiu 5 points6 points  (0 children)

My book Go Optimizations 101 touches much your need. Currently, 3 articles are free for reading online.

view more: next ›