tapirl

19 ms·

241.
by tapirl 4y ago
Personally, I am not against the proposal to add a "shrink(aMapOrSlice)` builtin function. In fact, there are more builtin functions on my wish list, such as "concat(slices)" and "decap(aSlice)". It is just that the
242.
by tapirl 4y ago
Yes, Go maps never shrink. This is good for most use cases in practice. Because in practice, map entry deletions happen seldom. And when map entry deletions are needed, users often hope maps don't shrink, to avoid potential later unnec
243.
by tapirl 4y ago
Even if strings.Compare is optimized, it is not always better than general comparison operators. Both strings.Compare and comparison operators have their respective best use scenarios.
244.
by tapirl 4y ago
Do you mean it is rare? Man, it is the key to do binary-searching. > ... based on their experiences with another language ... Sorry, this is language independent.
245.
by tapirl 4y ago
Evidences are provided in the article: https://sourcegraph.com/search?q=context:global+switch+strin...
246.
by tapirl 4y ago
It is reasonable. For Go case, Go is slower than C. For Zig case, zig is not slower than C++.
247.
No safe efficient ways to do three-way string comparisons in Go(go101.org)
175 points by tapirl 4y ago|150 comments
248.
by tapirl 4y ago
or Mesos?
249.
by tapirl 4y ago
Generics are totally helpless for runtime things. I would be good for the official runtime to be designed in a plugin way, so that third parties may experiment their own implementations of some aspects of the runtime.
250.
by tapirl 4y ago
It is just too simple to draw a conclusion. And IMHO, it is not very generics related.
251.
by tapirl 4y ago
You don't need to buy it. It is free for reading online, and most contents in my website are free. "insulting"? That is a too heavy word.
252.
by tapirl 4y ago
This article is too simple to get a full picture of Go custom generics. There are actually both good points and bad points. To get a comprehensive understanding of the current Go custom generics, please read: https://go101.org&#x
253.
by tapirl 4y ago
> Pretty much every other language has atomic mean "one of these will win, one will lose" Could you elaborate how "much every other language" implement it?
254.
Go Optimizations 101: suggestions and tricks for high performance Go programming(go101.org)
2 points by tapirl 4y ago|1 comments
255.
Use Go Maps Efficiently(go101.org)
2 points by tapirl 4y ago|0 comments
256.
Add one more line will improve Go program performance much(go101.org)
1 points by tapirl 4y ago|0 comments
257.
by tapirl 4y ago
> ... but also in other languages where it could happen, but you know, doesn't. My rust experience denies this.
258.
by tapirl 4y ago
> interface contains type constraints > interface is (or embeds) comparable Currently, not all interface types may be used as value types. Such types include comparable. It is very possible that all interface types could be used as va
259.
by tapirl 4y ago
Go tries to make each design element orthogonal. Type definition is not type embedding. There may be some discussions about this, hidden in the go-nuts forum. But I don't know how to filter them out.
260.
by tapirl 4y ago
There will be some permanent restrictions in Go custom design, but I think the `comparalbe` one is not one of them. My personal prediction is it will be solved before Go 1.21.
261.
by tapirl 4y ago
but is it cleanly? BTW, accessing common fields is temporarily disabled before releasing Go 1.18, because there is another fundamental problem which needs to be resolved firstly. ref: https://github.com/golang/go/i
262.
by tapirl 4y ago
The answer is complete. I just make some additional explanations here. 1) is totally generics unrelated. package main type T1 int func (T1) M() {} type T2 T1 func main() { var t2 T2 t2.M
263.
by tapirl 4y ago
It is obviously a typo.
264.
by tapirl 5y ago
Didn't it start as an open source database? then apple acquired it and made it close sourced, then open sourced it again after several years. It is weird that this DB has a good reputation which doesn't match its popularity.
265.
by tapirl 5y ago
It is strange that, although https://github.com/syndtr/goleveldb is used in the go-ethereum project for years, it is mentioned rarely (comparing to other go dbs).
266.
by tapirl 5y ago
Please note that not all features in the proposal are implemented yet.
267.
by tapirl 5y ago
And what is the intention to make the patent? The second way is actually more useful, not limited to unsigned ints.
268.
by tapirl 5y ago
1) surely. 2) just read: https://groups.google.com/g/golang-nuts/c/SXsgdpRK-mE/m/CT7UjJ3aBAAJ https://groups.google.com/g/golang-nuts/c/ZrVIhHCrR9o htt
269.
by tapirl 5y ago
Sometimes, it is not related to performance loss, it is related to implementation cleanness and complexity.
270.
by tapirl 5y ago
Now the non-deterministic implementation does more work than a deterministic implementation. It generates a random number and sorts the branches. The latter (sorts the branches) is not needed in the above pseudo code. Doubling the number of

More ›