tapirl

Aha, you are right. Smaller indexes are for least-significant bits.

Maybe I'm wrong, but should it be @clz instead?

Performance alone doesn't always imply verbosity, but combining it with other goals—such as increased security and more power std APIs—often does.

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 a worthy tradeoff.

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.

Thanks for the info. Updated.

Full List Of Open Source Physics Engines: https://www.tapirgames.com/blog/open-source-physics-engines

About Jolt, do you mean https://github.com/jrouwe/JoltPhysics ?

No specific examples. Just general GUI apps.

Slow means many: * long program launch times * inconsistent frame rates during runtime * noticeable lag in user interaction

web UI is slow, this is only reason when I don't it.

Having quick viewed all the chapters, the examples are too simplistic to fully demonstrate the full picture of Zig's syntax and semantics.

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 to such a small need. In facts, there are more problems in Go generics need to be solved earlier than this: https://go101.org/generics/888-the-status-quo-of-go-custom-g...

Go's generics design is the most clunky one among popular languages.

Are there any evidences which prove the process was done in a week?

It might be feature richer, but it is hard to say it is more powerful. Sometimes, features (especially constraints) will reduce powerlessness.

> ..., 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.

> ... 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 if the blog article mentions this.

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/go/issues/78170 and https://github.com/golang/go/issues/78169

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")
        } else {
            println("T is [4]uint16]")
        }
    }

    func main() {
        foo[[8]byte]()
    }

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{}]()
    }

Go is a language full of details: https://go101.org/details-and-tips/101.html

You claim listens right for this specified example. :D

It is just a demo.

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.

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()
    }
    
    func foo() {
        handle()
    }
    
    func main() {
        defer foo()
        panic("bye")
    }

see: https://go-review.googlesource.com/c/go/+/707755 and https://go-review.googlesource.com/c/go/+/664299

Looks for slices with lengths <= 32.

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 practice.

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.

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.

zig now.

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 maintaining strong backward compatibility.

[1]: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...