Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
tapirl
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
61.
▲
by
tapirl
1y ago
Source code of the benchmarks? At least, the False Sharing and AddVectors trick don't work on my computer. (I only benchmarked the two. The "Data-Oriented Design" trick is a joke to me, so I stopped benchmarking more.) And I
62.
▲
by
tapirl
1y ago
Just use it when it is needed. Try don't use it when it is unnecessary.
63.
▲
by
tapirl
1y ago
but still a Go newbie? The article's points feel overly simplistic/shallow and lack the depth you'd expect from an experienced Go programmer.
64.
▲
by
tapirl
1y ago
Go indeed has some problems. But IMHO, none described in this article is valid.
65.
▲
by
tapirl
1y ago
Go indeed has its problems. But the ones described in this article just prove the author is a Go newbie.
66.
▲
by
tapirl
1y ago
Normal function declarations. This is indeed a point which makes Zig inflexible.
67.
▲
by
tapirl
1y ago
It is weird to include "Rust" (a language) in the title. Readers might wonder what is replaced by Rust? Elasticsearch or MongoDB?
68.
▲
by
tapirl
1y ago
Listens your team had not sufficient review capacity at that time.
69.
▲
by
tapirl
1y ago
That is a general rule. Yours is a special case.
70.
▲
by
tapirl
1y ago
Isn't "jj new" what you need?
71.
▲
by
tapirl
1y ago
just when you face some unusual situations ...
72.
▲
by
tapirl
1y ago
If Go generics support typeclasses, things will be much better now. At least custom generics and built-in generics will be unified harmoniously. Now, the manners of type argument passing with the built-in `new` and `make` function and custo
73.
▲
by
tapirl
1y ago
It was also promoted as a language that prioritizes explicitness. But just look at the changes made in Go 1.22 (3-clause for-loop semantic change, [1]) and 1.23 (iterators, [2]). Magic implicitness was introduced in the two versions. Even w
74.
▲
by
tapirl
1y ago
> Generic is not about reducing how many keys you press but how you abstract your logic from the type. In go, it reduces a lot code making it safer and faster. No, this is not true for Go, at least for the current Go generics. At runtime
75.
▲
by
tapirl
1y ago
> This idea proves to be surprisingly powerful when it comes to expressing constraints on generic functions and types. Disagree. IMHO, this idea is the root cause of why Go generics is so complicate but also restrictive at the same time.
76.
▲
by
tapirl
1y ago
pros and cons vs. skia? Does it has a stable c API?
77.
▲
by
tapirl
1y ago
The bug is confirmed: https://github.com/golang/go/issues/71685
78.
▲
by
tapirl
1y ago
Be careful there are bugs and design flaws in Go iterators: https://go101.org/blog/2025-03-15-some-facts-about-iterators...
79.
▲
by
tapirl
1y ago
Because I am indeed experiencing the fact that AI systems do better and better.
80.
▲
by
tapirl
1y ago
I write code in notebook++ and never format my code. :D
81.
▲
by
tapirl
1y ago
I believe future AI systems can make correct answers. The rule is clearly specified in Go specification. BTW, I haven't found an AI system can get the correct output for the following Go code: package main import "fmt&q
82.
▲
by
tapirl
1y ago
For the OP's specified case, it is only a little language related. It is more a lib/framework related thing.
83.
▲
by
tapirl
1y ago
I have never seen any AI system could explain correctly on the following Golang code: package main func alwaysFalse() bool { return false } func main() { switch alwaysFalse() // don't format the
84.
▲
by
tapirl
1y ago
Comparing Rust with Electron is so weird. One is a language, the other is a lib/framework.
85.
▲
by
tapirl
1y ago
My surprise is typescipt is so slow. I have never used it yet, but I think will never too.
86.
▲
by
tapirl
2y ago
With Go toolchain [1.17, 1.23.1], it fails to build.
87.
▲
by
tapirl
2y ago
Cool! btw, README says Go 1.17+ is required, but go.mod says 1.23+.
88.
▲
by
tapirl
2y ago
Storing concrete values into interfaces often cause allocations, which has a larger impact on performance than inlining.
89.
▲
by
tapirl
2y ago
It seems you are proving Zig will not become very popular, but not Zig will not become more popular than Rust. I agree that Zig will not become very popular. It needs certain programming experiences to master it. But I'm quite sure it
90.
▲
by
tapirl
2y ago
Zig might not become very popular, but IMO, it will become more popular than Rust. Zig is good at all the areas Rust is good at. Zig is also good at game development which Rust is not good at. And Zig is better when integrating with C/
More ›