Inefficient transpiled code (heap escape allocs)

[romshark]

The following Dingo code (click to view)

package main

import "fmt"

type Order struct {
    ID        string
    Amount    int
    Validated bool
    Paid      bool
}

func fetchOrder(orderID string) Result[Order, string] {
    if orderID == "" {
        return Err[Order]("order id is empty")
    }

    if orderID == "missing" {
        return Err[Order]("order not found")
    }

    return Order{
        ID:        orderID,
        Amount:    125,
        Validated: false,
        Paid:      false,
    }
}

func validateOrder(order Order) Result[Order, string] {
    if order.Amount <= 0 {
        return Err[Order]("invalid amount")
    }

    order.Validated = true
    return order
}

func processPayment(order Order) Result[Order, string] {
    if !order.Validated {
        return Err[Order]("order must be validated before payment")
    }

    if order.ID == "declined" {
        return Err[Order]("payment was declined")
    }

    order.Paid = true
    return order
}

func processOrder(orderID string) Result[Order, string] {
    order := fetchOrder(orderID)?
    validated := validateOrder(order)?
    payment := processPayment(validated)?
    return payment
}

func main() {
    ids := []string{"A-100", "", "missing", "declined"}

    for _, id := range ids {
        fmt.Printf("processing %q\n", id)

        match processOrder(id) {
            Ok(order) => fmt.Printf("success: id=%s amount=%d validated=%t paid=%t\n\n", order.ID, order.Amount, order.Validated, order.Paid),
            Err(err) => fmt.Printf("error: %s\n\n", err),
        }
    }
}

Should be equivalent to the following Go code

package main

import (
	"errors"
	"fmt"
	"io"
	"testing"
)

type StdOrder struct {
	ID        string
	Amount    int
	Validated bool
	Paid      bool
}

var (
	errOrderIDEmpty    = errors.New("order id is empty")
	errOrderNotFound   = errors.New("order not found")
	errInvalidAmount   = errors.New("invalid amount")
	errNotValidated    = errors.New("order must be validated before payment")
	errPaymentDeclined = errors.New("payment was declined")
)

func stdFetchOrder(orderID string) (StdOrder, error) {
	if orderID == "" {
		return StdOrder{}, errOrderIDEmpty
	}

	if orderID == "missing" {
		return StdOrder{}, errOrderNotFound
	}

	return StdOrder{
		ID:        orderID,
		Amount:    125,
		Validated: false,
		Paid:      false,
	}, nil
}

func stdValidateOrder(order StdOrder) (StdOrder, error) {
	if order.Amount <= 0 {
		return StdOrder{}, errInvalidAmount
	}

	order.Validated = true
	return order, nil
}

func stdProcessPayment(order StdOrder) (StdOrder, error) {
	if !order.Validated {
		return StdOrder{}, errNotValidated
	}

	if order.ID == "declined" {
		return StdOrder{}, errPaymentDeclined
	}

	order.Paid = true
	return order, nil
}

func stdProcessOrder(orderID string) (StdOrder, error) {
	order, err := stdFetchOrder(orderID)
	if err != nil {
		return StdOrder{}, err
	}
	validated, err := stdValidateOrder(order)
	if err != nil {
		return StdOrder{}, err
	}
	payment, err := stdProcessPayment(validated)
	if err != nil {
		return StdOrder{}, err
	}
	return payment, nil
}

Benchmarks (click to open)

func BenchmarkProcessOrders(b *testing.B) {
	ids := []string{"A-100", "", "missing", "declined"}
	w := io.Discard

	for i := 0; i < b.N; i++ {
		for _, id := range ids {
			fmt.Fprintf(w, "processing %q\n", id)

			res := processOrder(id)
			if res.IsOk() {
				order := res.MustOk()
				fmt.Fprintf(w, "success: id=%s amount=%d validated=%t paid=%t\n\n", order.ID, order.Amount, order.Validated, order.Paid)
			} else {
				err := res.MustErr()
				fmt.Fprintf(w, "error: %s\n\n", err)
			}

		}
	}
}

func BenchmarkStdProcessOrders(b *testing.B) {
	ids := []string{"A-100", "", "missing", "declined"}
	w := io.Discard

	for i := 0; i < b.N; i++ {
		for _, id := range ids {
			fmt.Fprintf(w, "processing %q\n", id)

			order, err := stdProcessOrder(id)
			if err != nil {
				fmt.Fprintf(w, "error: %s\n\n", err)
			} else {
				fmt.Fprintf(w, "success: id=%s amount=%d validated=%t paid=%t\n\n",
					order.ID, order.Amount, order.Validated, order.Paid)
			}
		}
	}
}

The results are somewhat disappointing:

goos: darwin
goarch: arm64
pkg: dingotest
cpu: Apple M4 Pro
BenchmarkProcessOrders-14                2654920               431.1 ns/op           192 B/op         11 allocs/op
BenchmarkStdProcessOrders-14             2923504               412.9 ns/op            64 B/op          4 allocs/op
PASS
ok      dingotest       3.656s

Please correct me if I'm wrong, but the transpiler fails to produce an efficient Go equivalent and instead seems to alloc due to heap escaping of dgo.Result members:

type Result[T, E any] struct {
	Tag ResultTag // Exported for pattern matching
	Ok  *T        // Exported for pattern matching
	Err *E        // Exported for pattern matching
}

---

% dingo version
------------------------------------------------------------
     ▄▀▄    ▄▀▄       
     █  ▀▀▀▀▀  █      Dingo v0.14.0
     █  ^   ^  █      
     ▀▄   ▲   ▄▀      Runtime:  Go
       ▀▄▄▄▄▄▀        Website:  https://dingo-lang.org
      ▄█▀   ▀█▄       GitHub:   github.com/MadAppGang/dingo
     ██  ███  ██      
     ▀█▄▄▀ ▀▄▄█▀      

[dingo-reviewer]

@romshark You're not wrong — wrapping everything in dgo.Result[T, E] adds overhead vs native (T, error) returns. The good news: the pointer fields (*T, *E) you showed were already replaced with value types in pkg/dgo/result.go, so current builds avoid those specific heap escapes.

But the core issue remains:

Even with value fields, Result[T, E] carries both Ok T and Err E simultaneously — so Result[Order, string] is always sizeof(Order) + sizeof(string) + sizeof(ResultTag). That's inherently larger than (Order, error), and the Go compiler's escape analysis may still push it to the heap for larger structs.

The real fix:

The transpiler should generate native (T, error) return signatures in Go output, keeping Result[T, E] as Dingo-only syntax sugar. So fetchOrder(id)? would transpile to the exact if err != nil pattern you showed in your handwritten Go. We already do this for ? with error return types (see tests/golden/error_prop_02_multiple.go.golden) — extending it to cover Result return types fully is the logical next step.

Your benchmark is a great reference point. Targeting zero overhead vs idiomatic Go is explicitly in our success criteria (features/INDEX.md), and this issue makes a strong case for prioritizing it.

[romshark]

I am not willing to discuss issues with a bot who considers an expression "syntax sugar" while it's actually less sweet than the sugarless version. I will not waste my precious time with AI slop.

If you (the repo maintainer) ever read this message - please reconsider your use of AI in this context. We all use AI now, it's a powerful tool indeed, but this use case is IMHO pointless and harmful to the project because it adds no value to the discussion, instead it adds noise.

Suggestion

Alternatively, consider using AI as a "smart search engine" internally so you can save your time and focus on PRs you consider more important according to your goals. But don't let it spit slop in the discussion.

P.S.
Maybe I overreacted and should have just ignored the bot response. Sorry for the tone. But my feedback and suggestion still stand.

[alecgargett]

Please remove the "Zero runtime overhead." repeated multiple times in the README and "No performance penalty" until it's actually true and for now admit that it isn't there yet. Don't make people waste time using this new syntax with misleading marketing.