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

No, the diagram looks like a binary literal but it's actually backwards from that. Lane 0 becomes the LSB, but that's on the left of the diagram.

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

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.

That goal doesn’t imply verbosity is necessary- just a style thing which is contrary to its goal of being a better C, given verbosity is the opposite of most C.

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

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

fyi "Bevy XPBD" got renamed to Avian Physics (it is not xpbd based anymore) https://github.com/avianphysics/avian/issues/346

Thanks for the info. Updated.

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

Yep, there is a WASM build with full feature support: https://github.com/jrouwe/JoltPhysics.js

I open sourced a wasm build that has better typescript support here:

https://github.com/snackdotgame/jolt-ts

I also have an open source character controller for it

https://github.com/snackdotgame/jolt-ts-character-controller

I'm a big fan of jolt because they have a more incremental way of snapshotting physics state which really reduces the amount of serialization and memory you have to do if you want to implement deterministic netcode.

Nice, thanks for sharing! I'm definitely hoping to make use of the determinism for my netcode, if you have any useful write ups about that I'd be interested to read more.

Nice! JoltPhysics.js is quite finicky with typescript, having to have global variable Jolt of type Jolt and using that as a namespace.

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

I'm not a frontend developer, but seems fast to me. I'm surprised that the UI portion of this example takes so little CPU: https://youtu.be/7k0JNT6itaI

Now, the rest of the DSP code sure is faster in native.

What are examples where web UI is too slow for you?

Or do you mean large apps written in JS, which is a different topic?

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

That's neither examples nor a clarification if you're talking about JS or WASM.

No specific examples. Just general GUI apps.

Having quick viewed all the chapters, the examples are too simplistic to fully demonstrate 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 for 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...

Thanks for sharing. I had no idea Go's generics had this many limitations.

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

Exactly. We heard for years they wouldn't do generics it until they could do it right, and that was perfectly fine with me. Who wouldn't want a well thought out implementation? Then they released generics and it was like, "this is what you thought was the right way to do it?!"

What’s the approach they should have used instead and how would it be better? Especially in terms of keeping fast compile times and overall performance.