tapirl

10 ms·

91.
by tapirl 2y ago
Is tikv (still) a wrapper of RocksDB?
92.
by tapirl 2y ago
The homepage slide animation without JavaScript is impressive!
93.
by tapirl 2y ago
> I'm not sure you can actually break code with the new for-loop semantics (I mean, in real life situations). The linked issue thread provides real life cases. > It can probably fix some buggy code in the wild, but I have a hard
94.
by tapirl 2y ago
> Update go.mod. Be careful after you did this. Go has changed for-loop semantics since Go 1.22. When you change the go version to 1.22+ from 1.22-, you Go code has a probability to being broken: https://go101.org/blog&#x
95.
by tapirl 2y ago
I have to enable JavaScript to make it load. It seems the animation on the page requires JavaScript. So, I agree with @pzo that a GIF would be better in this case.
96.
by tapirl 2y ago
Are there any other choices? :D
97.
by tapirl 2y ago
@smw just says that tailscale is more convenient than dynamic DNS.
98.
by tapirl 2y ago
> ... replacing letters with email ... Some true, but not totally. The role of email has many differences from old-age letters. And letters are not only replaced with email, but also more modern communication manners. And the more modern
99.
by tapirl 2y ago
Another problem for years in Chrome is, if a line is wrapped between two Chinese words, Chrome will insert a space between them in rendering. (Firefox doesn't)
100.
by tapirl 2y ago
There is actually a proposal to make type constraints act as sum types: https://github.com/golang/go/issues/57644 But I doubt sum types will be supported perfectly in Go. The current poor-men's sum type
101.
by tapirl 2y ago
Okay, it is some reasonable if the operator is viewed as a behavior operator. But it is not, it is a type set operator.
102.
by tapirl 2y ago
> In particular, people tend to read it as the "sum type" operator, which it is not. I kind of wish the syntax has used & instead of |, what it is doing is closer to an "and" then an "or". I don't u
103.
by tapirl 2y ago
The difference between types.Implements and types.Satisfies is mainly caused by a history reason. It is just a tradeoff between keeping backward compatibility and theory perfection. It is pity that Go didn't support the "comparabl
104.
by tapirl 2y ago
The facts in my comments are for the people who need them. Maybe you are not one of them. But then why do you so care about it?
105.
by tapirl 2y ago
First, Go Official has never expressed the same opinion as you officially. In fact, the "go run GoSourceFilesWithoutGoDotModFile" command is still supported in 1.22 and latest Go toolchain versions. Second, the idea that rarity de
106.
by tapirl 2y ago
> You need to stop doing this. It's now at the point where you're derailing every other Go thread with this. This is not true. I haven't posted any comments in many Go threads. I only comment when it is related. And most g
107.
by tapirl 2y ago
I wrote many Go articles praising Go: https://go101.org/ I am neither a no-brainer Go hater nor a no-brainer Go lover. Good is good, bad is bad. All my articles/posts are based on facts.
108.
by tapirl 2y ago
I only post facts. :D
109.
by tapirl 2y ago
It is not that simple. For some Go scripts without go.mod involved, Go 1.22.n toolchains break backward compatibility for sure. Go core team have admitted this but refused to fix it for Go 1.22.n toolchains: https://github.com&#x
110.
by tapirl 2y ago
> One thing that hasn't changed is their amazing commitment to not breaking existing code. Er, are you sure? * https://x.com/zigo_101/status/1856173025839960333 * https://x.com/zigo_101&#x2
111.
by tapirl 2y ago
> Go 1.22 made variables introduced by for loops scoped per iteration, rather than per loop, addressing a long-standing language “gotcha”. This does fixes the "for-range" loop gotcha, but brings several gotchas to the 3-clause
112.
by tapirl 2y ago
You should read that article carefully. Some Go core team members don't agree with you: https://github.com/golang/go/issues/66156
113.
by tapirl 2y ago
Copernicus was in the same position. :)
114.
by tapirl 2y ago
The problems are right there. But some people choose to turn a blind eye.
115.
by tapirl 2y ago
There might be some bugs in .2: https://github.com/golang/go/issues/70035
116.
by tapirl 2y ago
It indeed is. Please read https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... and https://github.com/golang/go/issues/66156
117.
by tapirl 2y ago
Please note, currently, there are no tools to detect the new footguns created by the new semantics of 3-clause "for;;" loops: https://github.com/golang/go/issues/66156 > The second step is to kee
118.
by tapirl 2y ago
Agree, he just had bad public relations.
119.
by tapirl 2y ago
Rust is harder than C++. It is C+++.
120.
by tapirl 2y ago
> Go is supposed to be an improvement over C for most programming tasks. This is not true. s/Go/Zig is true. That is why I'm switching to Zig now.

More ›