Looking at the first example, "The "if err != nil" problem": note how errors got noticeable worse... If something breaks, you no longer know if it's fetch vs validation vs payment.

I am not an "establishment" but this terrifies me. Error message quality already took a nosedive when people switch from languages with backtraces into Go. Slowly, after pain of thousands debugging sessions, people are realizing that "return nil, err" is bad, and fmt.Errorf should be used everywhere. And how we have new languages undoing this all again?

I don't find a Result type to be particularly useful unless I can chain them. That doesn't work well unless they're generic and type-checked.

Declaring a v1.0 for 2025 seems optimistic given it seems to have little actual usage guessing from the few/general open issues.

Some of the features seem similar to Borgo? Would love for a Go ‘successor’ to take off.

I assume it is generating Go as an "intermediate language". What's the percentual overhead of this, are measurements available? Even if Go's AST and IRs are "internal", the source is still available and one could in principle directly adapt to this IR from the Dingo frontend. I ask myself, whether this would bring a significant advantage (mostly in terms of latency and throughput, maybe in terms of source level debugging). Does anyone have an experience founded answer?