Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
tapirl
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
tapirl
2mo ago
Aha, you are right. Smaller indexes are for least-significant bits.
2.
▲
by
tapirl
2mo ago
Maybe I'm wrong, but should it be @clz instead?
3.
▲
by
tapirl
2mo ago
Performance alone doesn't always imply verbosity, but combining it with other goals—such as increased security and more power std APIs—often does.
4.
▲
by
tapirl
2mo ago
Zig is indeed verbose in some aspects, but not overall. For example, its `try error-union` syntax eliminates a lot of boilerplate code. The main reason why Zig is verbose in some aspects is the main goal of Zig is program performance. It is
5.
▲
by
tapirl
3mo ago
Unlike Google, the AI wave appears to deliver positive revenue impacts for Microsoft. The company does need to integrate the new AI-human-machine interface into its application development SDKs.
6.
▲
by
tapirl
3mo ago
Thanks for the info. Updated.
7.
▲
by
tapirl
3mo ago
Full List Of Open Source Physics Engines: https://www.tapirgames.com/blog/open-source-physics-engines
8.
▲
by
tapirl
3mo ago
About Jolt, do you mean https://github.com/jrouwe/JoltPhysics ?
9.
▲
by
tapirl
3mo ago
No specific examples. Just general GUI apps.
10.
▲
by
tapirl
3mo ago
Slow means many: * long program launch times * inconsistent frame rates during runtime * noticeable lag in user interaction
11.
▲
by
tapirl
3mo ago
web UI is slow, this is only reason when I don't it.
12.
▲
by
tapirl
3mo ago
Having quick viewed all the chapters, the examples are too simplistic to fully demonstrate Zig's syntax and semantics.
13.
▲
by
tapirl
4mo ago
Yes, the sugar is just to make chain calls with parameter types possible. The sugar reflects the limitation of the basic of Go generics design. Now they would make the language even more complex for such a small need. In facts, there are mo
14.
▲
by
tapirl
4mo ago
Go's generics design is the most clunky one among popular languages.
15.
▲
by
tapirl
4mo ago
Are there any evidences which prove the process was done in a week?
16.
▲
by
tapirl
4mo ago
It might be feature richer, but it is hard to say it is more powerful. Sometimes, features (especially constraints) will reduce powerlessness.
17.
▲
by
tapirl
4mo ago
> ..., comptime that is more powerful than Zig It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.
18.
▲
by
tapirl
6mo ago
> ... and perhaps `go fix` should add a check for this ( This is an impossible task. For a library function, you can't know whether or not the function is defer called. Maybe this is not an important problem. But it would be better
19.
▲
by
tapirl
6mo ago
another: package main type T = [8]byte var a T //go:fix inline func foo() T { return T{} } func main() { if foo() == a { } } filed: https://github.com/golang/g
20.
▲
by
tapirl
6mo ago
similar: package main //go:fix inline func foo[T [8]byte | [4]uint16]() { var v T var n byte = 1 << len(v) >> len(v) if n == 0 { println("T is [8]byte")
21.
▲
by
tapirl
6mo ago
Another example (fixable): package main import "unsafe" //go:fix inline func foo[T any]() { var t T _ = 1 / unsafe.Sizeof(t) } func main() { foo[struct{}]() }
22.
▲
by
tapirl
6mo ago
You claim listens right for this specified example. :D It is just a demo.
23.
▲
by
tapirl
6mo ago
As I have mentioned, no ways to fix it. Because it is hard to know whether or not the handle function is called in a deferred call.
24.
▲
by
tapirl
6mo ago
It looks the following code will be rewritten badly, but no ways to avoid it? If this is true, maybe the blog article should mention this. package main //go:fix inline func handle() { recover() }
25.
▲
by
tapirl
7mo ago
see: https://go-review.googlesource.com/c/go/+/707755 and https://go-review.googlesource.com/c/go/+/664299 Looks for slices with lengths <= 32.
26.
▲
by
tapirl
8mo ago
This one is just an example to demo one case of backward-capability breaking. > All the examples in that article are very exotic. Have you carefully read that article? All? You must be kidding. The article shows several cases used in pra
27.
▲
by
tapirl
8mo ago
The change made in Go 1.22 for 3-clause-for loops is not a new feature. It simply broke backward compatibility and old Go principles. It is much worse than C++'s stuff features.
28.
▲
by
tapirl
8mo ago
It is only right for for-each loops. For 3-clause-for loops, if you have read https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... carefully, it is hard to think it is right.
29.
▲
by
tapirl
8mo ago
zig now.
30.
▲
by
tapirl
8mo ago
Go was my favorite language for a long time, and I have written many books and articles about it. However, since the release of Go 1.22 [1], that is no longer the case. Go 1.22 damaged Go's reputation for promoting explicitness and mai
More ›