Forem: ColaFanta

Go Admin Dashboard for E-Commerce with HTMX, Templ UI, and GORM - Part 1

ColaFanta — Tue, 05 May 2026 09:00:00 +0000

Go can be used for server-rendered web apps as well as APIs. With templ for views and htmx for browser interactions, it is possible to build an admin UI in a mostly Go-first workflow.

In this series, we will build an e-commerce admin dashboard with Fiber, HTMX, Templ UI, and GORM. Part 1 focuses on the UI foundation: starting a small server, generating UI components, building a landing page, and composing a reusable dashboard layout.

The code samples below are intentionally simplified. They are closer to pseudocode than copy-paste production code, so the focus stays on structure instead of project-specific details.

Prerequisites

Set up the server

To begin, a very small Fiber server is enough. It only needs to serve static assets, render the landing page, and listen on a port.

func main() {
    app := fiber.New()

    app.Static("/assets", "./assets")
    app.Get("/", RenderTempl(LandingPage))

    app.Listen(":3000")
}

That is enough for a first success point. If / renders correctly, the server, the template engine, and the static files are all connected.

Import UI components

Templ UI follows a generated-source approach. Instead of depending on a remote component package at runtime, you generate the component files into your own project and edit them like normal code.

Install the CLI:

go install github.com/templui/templui/cmd/templui@latest

Then initialize it and add components:

templui init
templui add "*"

For a tutorial, generating everything is convenient because it makes experimentation easier. In a real project, you can add only the components you plan to use.

Make a landing page

The landing page is a good first screen because it proves the layout works and gives us somewhere to place the first navigation buttons.

Here is a simplified .templ page component:

templ LandingPage(c fiber.Ctx) {
    @layout.LandingLayout() {
        <div class="h-full flex justify-center items-center">
            <div class="flex flex-col gap-4 items-center justify-center px-4 w-full max-w-2xl">
                <div class="text-center space-y-4">
                    <h1 class="text-5xl font-bold tracking-tight">Fanta Admin</h1>
                    <p class="text-muted-foreground text-lg max-w-md mx-auto">
                        A simple admin panel built with Go, HTMX, and templ.
                    </p>
                </div>
                <div hx-boost="true" hx-indicator="#gprogress" class="flex gap-3">
                    @button.Button(button.Props{Href: "/login"}) {
                        Login
                    }
                    @button.Button(button.Props{Variant: "outline", Href: "/signup"}) {
                        Sign Up
                    }
                </div>
            </div>
        </div>
    }
}

The page itself stays small because the shared wrapper is moved into a layout component:

templ LandingLayout() {
    @BaseLayout() {
        <div class="h-full flex flex-col">
            @block.Navbar()
            <main class="flex-1">
                { children... }
            </main>
        </div>
    }
}

This pattern is useful early on: put shared structure in layouts, and keep page components focused on their own content.

Make the dashboard layout

An admin page usually needs more structure than a landing page. A common shape is a sidebar for navigation and a main content area for the current page.

With templ, that can still be written as a normal component:

templ AdminLayout(c fiber.Ctx) {
    @layout.BaseLayout() {
        @sidebar.Layout() {
            @sidebar.Sidebar(sidebar.Props{
                Collapsible: sidebar.CollapsibleIcon,
                Variant:     sidebar.VariantFloating,
            }) {
                @sidebar.Header() {
                    <div class="px-2 py-2 font-semibold">Admin</div>
                }

                @sidebar.Content() {
                    @sidebar.Menu() {
                        @sidebar.MenuItem() {
                            @sidebar.MenuButton(sidebar.MenuButtonProps{Href: "/api/dashboard"}) {
                                Dashboard
                            }
                        }
                        @sidebar.MenuItem() {
                            @sidebar.MenuButton(sidebar.MenuButtonProps{Href: "/api/products"}) {
                                Products
                            }
                        }
                        @sidebar.MenuItem() {
                            @sidebar.MenuButton(sidebar.MenuButtonProps{Href: "/api/users"}) {
                                Users
                            }
                        }
                    }
                }
            }

            @sidebar.Inset() {
                <div class="flex h-full flex-col">
                    <header class="px-6 py-4 border-b font-semibold">
                        Admin Panel
                    </header>
                    <main class="px-10 py-6">
                        { children... }
                    </main>
                </div>
            }
        }
    }
}

Once that layout exists, a page can plug into it with very little code:

templ DashboardPage(c fiber.Ctx) {
    @AdminLayout(c) {
        <div class="space-y-2">
            <h1 class="text-3xl font-bold">Dashboard</h1>
            <p class="text-muted-foreground">
                Welcome to the admin panel.
            </p>
        </div>
    }
}

And the route can stay simple as well:

app.Get("/api/dashboard", RenderTempl(DashboardPage))

That parent-child composition is the main idea. The layout owns the shell, and each page provides the content.

A `Fiber` adapter for `templ`

templ renders through Go's standard net/http flow, while Fiber uses its own handler type. To connect the two, a small adapter is useful.

For tutorial purposes, the idea can be expressed like this:

func RenderTempl(page func(fiber.Ctx) templ.Component) fiber.Handler {
    return func(c fiber.Ctx) error {
        component := page(c)
        httpHandler := templ.Handler(component)
        return adaptor.HTTPHandler(httpHandler)(c)
    }
}

The important part is not the exact implementation. The important part is that templ can render through an ordinary HTTP handler, and Fiber can wrap that handler through its adapter.

Once this helper exists, using templ pages in routes feels natural.

Wire things up with HTMX

At this point, the pages already render. HTMX adds smoother navigation and form handling without requiring a separate frontend framework.

The root layout can load the scripts and define a global loading indicator:

templ BaseLayout() {
    <!DOCTYPE html>
    <html lang="en">
        <head>
            <meta charset="UTF-8"/>
            <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
            <link href="/assets/css/output.css" rel="stylesheet"/>
            <link href="/assets/css/gprogress.css" rel="stylesheet"/>
            <script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js"></script>
            <script src="https://cdn.jsdelivr.net/npm/hyperscript.org@0.9.14/dist/_hyperscript.min.js"></script>
            <title>Admin</title>
        </head>
        <body class="h-full" hx-indicator="#gprogress">
            <div id="gprogress" class="gprogress"></div>
            { children... }
        </body>
    </html>
}

Then page-level navigation can stay declarative. For example, the landing page buttons already use hx-boost="true", which tells HTMX to enhance the links inside that container.

Forms can use the same idea. A simplified login component might look like this:

templ LoginPage(c fiber.Ctx) {
    @layout.LandingLayout() {
        <div class="h-full flex justify-center items-center">
            <form
                hx-boost="true"
                hx-swap="none"
                method="post"
                action="/auth/unpw/login"
                class="flex flex-col gap-3 min-w-sm"
                _="on htmx:afterRequest
                    if event.detail.successful then
                        set window.location.href to '/api/dashboard'
                    end"
            >
                <h1 class="text-2xl font-bold">Login</h1>
                <input name="user" type="text" placeholder="Username"/>
                <input name="passwd" type="password" placeholder="Password"/>
                <button type="submit">Login</button>
            </form>
        </div>
    }
}

The main idea is that the page still looks like normal server-rendered HTML, but HTMX can enhance link clicks and form submissions when needed.

Part 1 Summary

At this point, we have the basic UI foundation in place:

a small Fiber server
generated Templ UI components
a landing page
a reusable admin layout
a small templ adapter for Fiber
HTMX-enhanced navigation and form submission

You should end up with a result similar to this:

If you want the full boilerplate, the complete source is here:

https://github.com/ColaFanta/go-simple-admin-template

Async/Await-like pattern in Go to make concurrency simple, robust, less boilerplate

ColaFanta — Mon, 27 Apr 2026 05:31:24 +0000

disclaimer:
It is just a pattern that wraps Goroutine and channel. It is still Goroutine underneath. It is not bringing "coloring" to Go code. Functions still call other functions as normal functions, without the need to distinguish async/sync ones.

Goroutine

For beginners of Go who come from other "colored" languages like JavaScript, one big difference in Golang's mental model is Goroutine.

func Add() int {
  a := 1
  b := 2
  var c int
  doneSignal := make(chan struct{}, 1)
  go func() { // fire a function running in parallel with Goroutine
    c = 3 // able to edit variable outside the local scope
    go func() {}() // able to start child Goroutine inside a goroutine
    doneSignal <- struct{}{}
  }()
  <- doneSignal // wait for the goroutine to complete
  return a + b + c
}

Unlike JavaScript, you can fire a function that runs in parallel anywhere in your function code without making that function async. It is one key strength that makes Golang stand out against other languages

Async/Await

If you came from "colored" languages, you can make it into your familiar Async/Await while not breaking Golang's simplicity, just by wrapping it up a bit.

func Async(fn func(), doneSignal chan struct{}) {
  go func() {
    fn()
    doneSignal <- struct{}{}
  }()
}

func Await(doneSignal chan struct{}) {
  <- doneSignal
}

func Add() int {
  a := 1
  b := 2
  sumCh := make(chan int, 1)
  doneSignal := make(chan struct{}, 1)

  Async(func() {
    sumCh <- a + b + 3
  }, doneSignal)

  Await(doneSignal)
  return <-sumCh
}

Better Async/Await

We can make this even better if these problems can be solved:

A done signal must be repeatedly created for each Goroutine.
When encapsulation is demanded, passing parameters and return values becomes hard.
No easy way to stop a running Goroutine.
When child Goroutine outlives parent, things get worse to manage.
How about error handling inside and outside of Goroutine?

These are real problems my own team project faced when applying Go concurrency. We figured out one solution and it worked well. So I distilled the most general and reusable part of it and made this library go-opera. Making error handling better is also another goal of this library.

Without wasting time, your final Async/Await pattern would look like this:

// This code is from a real Fiber http handler, which queries both database record count and record data concurrently.
func(ctx context.Context, q *gorm.DB, p Params) error {
    return opera.Do(func () any {
        logTask := opera.Async(ctx, func(ctx context.Context) opera.Result[opera.Unit] {
            return opera.TryPass(pushLogsToRemote(ctx))
        })

        visitTask := opera.Async(ctx, func(ctx context.Context) opera.Result[opera.Unit] {
            return opera.TryPass(redisClient.Incr(ctx, "visit:"+p.Path).Err())
        })

        countTask := opera.Async(ctx, func(ctx context.Context) opera.Result[int64] {
            return opera.Try(q.Count(ctx, "*"))
        })
        dataTask := opera.Async(ctx, func(ctx context.Context) opera.Result[[]T] {
            size := p.Size.Or(20)
            offset := (p.Page.Or(1) - 1) * size
            q.Offset(offset).Limit(size)
            return opera.Try(q.Find(ctx))
        })
        // Side tasks still report errors through Result, so Await them as well.
        opera.Await(ctx, logTask).Yield()
        opera.Await(ctx, visitTask).Yield()

        // Getting results of two async tasks in one line
        count, data := opera.Await(ctx, countTask).Yield(), opera.Await(ctx, dataTask).Yield()

        return nil
    }).Err()
}

What if you do it all with goroutine?

// Pure goroutine version of the above example (no go-opera).
func HandleRequest(parent context.Context, q *gorm.DB, p Params) error {
  ctx, cancel := context.WithTimeout(parent, 2*time.Second)
  defer cancel()

  type countRes struct { 
    v int64
    err error 
  }
  type dataRes struct { 
    v []T
    err error 
  }

  countCh := make(chan countRes, 1)
  dataCh := make(chan dataRes, 1)
  logErrCh := make(chan error, 1)
  visitErrCh := make(chan error, 1)

  // Start concurrent tasks
  go func() {
    cnt, err := q.Count(ctx, "*")
    countCh <- countRes{cnt, err}
  }()

  go func() {
    size := p.Size.Or(20)
    offset := (p.Page.Or(1) - 1) * size
    q.Offset(offset).Limit(size)
    data, err := q.Find(ctx)
    dataCh <- dataRes{data, err}
  }()

  // Side tasks (non-fatal)
  go func() {
    logErrCh <- pushLogsToRemote(ctx)
  }()

  go func() {
    visitErrCh <- redisClient.Incr(ctx, "visit:"+p.Path).Err()
  }()

  // Await side tasks (log errors, but don't fail request)
  if err := <-logErrCh; err != nil {
    log.Println("logTask failed:", err)
  }
  if err := <-visitErrCh; err != nil {
    log.Println("visitTask failed:", err)
  }

  // Await main tasks and return early on error
  cr := <-countCh
  if cr.err != nil {
    return cr.err
  }
  dr := <-dataCh
  if dr.err != nil {
    return dr.err
  }

  count := cr.v
  data := dr.v

  _ = count
  _ = data

  return nil
}

The above raw Goroutine code is just a simple rewrite. If error propagation and goroutine cancellation added, code would become even more bloated.

Introducing go-opera

What go-opera brings you for async/await-like programming:

Better encapsulation

Simple Goroutines return result of execution by just editing outer variable directly:

func LoadUsername() string {
    var username string
    doneSignal := make(chan struct{}, 1)

    go func() {
        username = fetchUsernameFromDB()
        doneSignal <- struct{}{}
    }()

    <-doneSignal
    return username
}

This is bad for encapsulation and function composition.
With go-opera, you start a Goroutine by using Async, and the return value of the execution is automatically encapsulated for you. You get that value with Await.

func LoadUsername(ctx context.Context) string {
    usernameChannel := opera.Async(ctx, func(ctx context.Context) opera.Result[string] {
        return opera.Try(fetchUsernameFromDB(ctx))
    })

    username := opera.Await(ctx, usernameChannel).OrPanic()
    return username
}

Under the hood, Async gives you a chan through which the final execution result is passed to you. And Await simply blocks the main routine and waits for that result.
That follows the nature of Golang, not "coloring" it.

No need for manual `done` signal or `WaitGroup`

Using WaitGroup, you have to manually count done signal:

func LoadDashboard() (int, []Order, error) {
    var wg sync.WaitGroup

    var count int
    var orders []Order
    var countErr error
    var ordersErr error

    wg.Add(2)

    go func() {
        defer wg.Done()
        count, countErr = repo.CountOrders()
    }()

    go func() {
        defer wg.Done()
        orders, ordersErr = repo.ListOrders()
    }()

    wg.Wait()

    if countErr != nil {
        return 0, nil, countErr
    }
    if ordersErr != nil {
        return 0, nil, ordersErr
    }
    return count, orders, nil
}

With go-opera, as said above, every Async is actually giving a chan, and that chan delivers the final Result to unblock the main routine execution, so that you do not need to manually create done signal or use WaitGroup for this pattern at all.

Better error handling

It is even more crucial to properly handle failable operations in concurrency code. The conventional val, err := way of handling error does not make life easier because chan type does not accept multi-return values.

userCh := make(chan User, 1)
errCh := make(chan error, 1)

go func() {
    user, err := repo.FindUser(id)
    if err != nil {
        errCh <- err
        return
    }
    userCh <- user
}()

select {
case user := <-userCh:
    _ = user
case err := <-errCh:
    return err
}

What go-opera does is stick to Result type, enforcing Async, Await, and all other related utility functions to use Result type as intermediate processing value. You will always get the error information no matter how deep you nest Async.

userTask := opera.Async(ctx, func(ctx context.Context) opera.Result[User] {
    return opera.Try(repo.FindUser(ctx, id))
})

user, err := opera.Await(ctx, userTask).Get()

Structured concurrency

Structured concurrency is a widely promoted pattern for modern concurrency design. go-opera Async/Await helps you create such concurrency with ease. All you have to do is give the same context.Context instance. When that context.Context is Done, all Goroutines created by go-opera Async/Await will be cancelled. You can also derive context.Context from parent, which enforces child Goroutine to not outlive its parent.

func HandleRequest(parent context.Context) opera.Result[opera.Unit] {
  return opera.Do(func() opera.Unit {
    ctx, cancel := context.WithTimeout(parent, 2*time.Second)
    defer cancel()

    reportTask := opera.Async(ctx, func(ctx context.Context) opera.Result[Report] {
      return opera.Try(buildReport(ctx))
    })

    auditTask := opera.Async(ctx, func(ctx context.Context) opera.Result[opera.Unit] {
      return opera.TryPass(writeAuditLog(ctx))
    })

    report := opera.Await(ctx, reportTask).Yield()
    opera.Await(ctx, auditTask).Yield()

    return opera.U
    })
}

func main() {
  ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
  HandleRequest(ctx)
  cancel // It cancels all goroutines created by HandleRequest
}

There are also other useful utility functions for Async/Await-like programming:

AwaitAll - helps conveniently await a slice of tasks and wraps return values into one single result.
AwaitFirst - wait for the first accompleted task.
AwaitZipN - helps collect N tasks with type safety via Go generics.

`AwaitAll`

Use AwaitAll when several async tasks are all required for the next step. It preserves input order, treats nil channels as empty values, and returns early if any task fails.

countTask := opera.Async(ctx, func(ctx context.Context) opera.Result[int] {
  return opera.Try(repo.CountOrders(ctx))
})

ordersTask := opera.Async(ctx, func(ctx context.Context) opera.Result[[]Order] {
  return opera.Try(repo.ListOrders(ctx))
})

all := opera.AwaitAll[any](ctx, countTask, ordersTask).Yield()

count := opera.MayCast[int](all[0]).OrEmpty()
orders := opera.MayCast[[]Order](all[1]).OrEmpty()

If all channels have the same type, use AwaitAllT instead:

prices := opera.AwaitAllT(ctx, priceTask1, priceTask2, priceTask3).Yield()

`AwaitAllSettled`

Use AwaitAllSettled when you want every task outcome, including failures, instead of stopping on the first error. The returned slice keeps the same order as the input channels.

results := opera.AwaitAllSettled[any](ctx, profileTask, ordersTask, auditTask)

for _, result := range results {
  if err := result.Err(); err != nil {
    log.Println("task failed:", err)
    continue
  }
  log.Println("task value:", result.Yield())
}

For homogeneous channels, AwaitAllSettledT keeps the call site type-safe:

results := opera.AwaitAllSettledT(ctx, job1, job2, job3)

`AwaitFirst`

Use AwaitFirst when several alternative operations can satisfy the same need and you want the first successful one. It returns both the value and the index of the winning channel. Errors are ignored until all tasks fail.

cachedTask := opera.Async(ctx, func(ctx context.Context) opera.Result[User] {
  return opera.Try(cacheRepo.FindUser(ctx, id))
})

primaryTask := opera.Async(ctx, func(ctx context.Context) opera.Result[User] {
  return opera.Try(primaryRepo.FindUser(ctx, id))
})

winner := opera.AwaitFirstT(ctx, cachedTask, primaryTask).Yield()
user := winner.V0
sourceIndex := winner.V1

`AwaitZip`, `AwaitZip3` ... `AwaitZip9`

Use the zip helpers when you want results from multiple tasks as a typed tuple instead of a []any. This is especially useful for heterogeneous tasks.

countTask := opera.Async(ctx, func(ctx context.Context) opera.Result[int64] {
  return opera.Try(repo.CountOrders(ctx))
})

ordersTask := opera.Async(ctx, func(ctx context.Context) opera.Result[[]Order] {
  return opera.Try(repo.ListOrders(ctx))
})

summary := opera.AwaitZip(ctx, countTask, ordersTask).Yield()
count, orders := summary.V0, summary.V1

Give it a try: go-opera and tell me your feedback👍

Flutter Error Handling with Result, introducing neverthrow_dart

ColaFanta — Sun, 12 Apr 2026 08:21:26 +0000

Flutter Error Handling with `Result` in `neverthrow_dart`

Building a robust Flutter app is hard because every layer can fail: network, storage, auth, parsing, and background work. That makes error handling part of the design, not just cleanup code.

Since Dart 3 introduced sealed classes and patterns, typed error handling fits much more naturally in Dart. One of the most useful approaches is the Result pattern.

Why `Result` is useful

Before Dart 3, many libraries brought this idea to Dart through Either, TaskEither, or custom Result types. The motivation is still the same:

A fallible operation becomes explicit in the type signature, so callers know they must handle failure.
Success and failure travel through the same return value, which keeps the happy path readable and removes a lot of repetitive try/catch code.
Mapping, recovery, and testing become simpler because both branches are regular values.

Why `neverthrow_dart`

neverthrow_dart exists because many Result-style APIs look good in toy examples, but become awkward in real app code.

1. Naive `Result` types often lose value semantics

If a Result is just a plain wrapper object, it is easy to lose immutability and value equality.

final a = MyResult.ok(1);
final b = MyResult.ok(1);

print(a == b); // false

2. Without error propagation, you escape `try/catch` only to land in match hell

Some libraries remove exceptions, but do not give you a satisfying propagation mechanism. You leave try/catch, but land in nested matching instead.

Result<BookingReceipt> reserveRoom() {
  return getGuestNameInput().match(
    (guestName) => getGuestIdInput().match(
      (guestId) => verifyGuestIdFormat(guestId).match(
        (verifiedId) => getStayDateInput().match(
          (stayRange) => validateStayRange(stayRange).match(
            (validRange) => bookRoom(
              guestName: guestName,
              guestId: verifiedId,
              stayRange: validRange,
            ),
            (error) => Err(error),
          ),
          (error) => Err(error),
        ),
        (error) => Err(error),
      ),
      (error) => Err(error),
    ),
    (error) => Err(error),
  );
}

That is the gap $do and $doAsync are trying to close. The flow should read like normal Dart.

3. Some libraries keep the error but lose the stack trace

Dart separates Exception and StackTrace. If a library stores only the exception, the most useful debugging information is already gone.

final class SimpleErr<T> {
  final Exception error;

  SimpleErr(this.error);
}

That looks harmless until a production error reaches your logs with no useful origin.

4. Splitting sync and async results creates a conversion tax

Another common design is to split sync and async into separate types, for example Either and TaskEither. That sounds tidy, but it means every time sync and async code meet, you have to lift and convert values manually.

TaskEither<Exception, UserCard> loadUserCard(String id) {
  return fetchUser(id).flatMap((userResponse) {
    final userEither = parseUserJson(userResponse);

    return TaskEither.fromEither(userEither).flatMap((user) {
      return fetchAvatar(user.avatarId).flatMap((avatarResponse) {
        final avatarEither = parseAvatarJson(avatarResponse);

        return TaskEither.fromEither(
          avatarEither.map((avatar) => UserCard(user: user, avatar: avatar)),
        );
      });
    });
  });
}

That explicit Either to TaskEither conversion step adds friction to code that should compose naturally.

5. `Result<T, E>` is elegant in theory, but awkward in Dart

Typed error channels work best in languages with ergonomic union types. Dart does not have that for arbitrary error combinations, so Result<T, E> often pushes you into widening, wrapping, and re-wrapping error types.

// Hypothetical API, not this package.
Result<String, ReadFileError> readFileText(String path);
Result<Config, ParseConfigError> parseConfig(String raw);
Result<App, BuildAppError> buildApp(Config config);

Result<String, LoadConfigError> loadConfigText(String path) {
  return switch (readFileText(path)) {
    Ok(:final text) => Ok(text),
    Err(:final error) => Err(LoadConfigReadError(error)),
  };
}

Result<Config, BootstrapError> bootstrapConfig(String path) {
  return switch (loadConfigText(path)) {
    Ok(:final text) => switch (parseConfig(text)) {
      Ok(:final config) => Ok(config),
      Err(:final error) => Err(BootstrapParseError(error)),
    },
    Err(:final error) => Err(BootstrapLoadError(error)),
  };
}

Result<App, BootstrapError> bootstrapApp(String path) {
  return switch (bootstrapConfig(path)) {
    Ok(:final config) => switch (buildApp(config)) {
      Ok(:final app) => Ok(app),
      Err(:final error) => Err(BootstrapBuildError(error)),
    },
    Err(:final error) => Err(error),
  };
}

The problem is not just verbosity. Every layer has to invent one more wrapper error just so the generic E type lines up again.

With Result<T>, the same flow can stay focused on the success path and only translate errors at the boundary where you actually want domain-specific failures:

Result<App> bootstrapApp(String path) {
  return $do(() {
    final text = readFileText(path).$;
    final config = parseConfig(text).$;
    return buildApp(config).$;
  });
}

Result<App> startApp(String path) {
  return bootstrapApp(path).mapErr((error, _) => switch (error) {
    ReadFileError() => const AppStartupFailure.configNotFound(),
    ParseConfigError() => const AppStartupFailure.invalidConfig(),
    BuildAppError() => const AppStartupFailure.bootstrapFailed(),
    _ => AppStartupFailure.unknown(error),
  });
}

This is why neverthrow_dart uses Result<T> and leans on Dart exceptions as the error value. It keeps composition simple while still letting you define domain-specific exception types.

Real-world example of `neverthrow_dart`

Here are two examples that show the part I find most useful: write several fallible steps in a straight line with .$, then convert back to exceptions only at the framework boundary.

1. Compose multiple fallible steps with `$doAsync`

FutureResult<BookingReceipt> reserveRoom() => $doAsync(() async {
  final guestName = getGuestNameInput().$;
  final guestId = getGuestIdInput().flatMap(verifyGuestIdFormat).$;
  final stayRange = getStayDateInput().flatMap(validateStayRange).$;

  final receipt = await hotelApi.bookRoom(
      guestName: guestName,
      guestId: guestId,
      stayRange: stayRange,
    ).mapErr((error, _) => switch (error) {
    HttpException(statusCode: 400) => const BookingFailure.invalidRequest(),
    HttpException(statusCode: 404) => const BookingFailure.roomNotFound(),
    HttpException(statusCode: 409) => const BookingFailure.roomAlreadyBooked(),
    _ => BookingFailure.unknown(error),
  }).$;

  return receipt;
});

This is the appealing part. Each step can fail, but the code still reads top to bottom like ordinary async Dart:

.$ extracts the successful value.
flatMap(...) and mapErr(...) keep validation and error translation in the same flow.

If any step fails, $doAsync stops immediately and returns an Err.

In a hooks-based UI, you can keep the Result in local state and react to it explicitly:

final bookingResult = useState<Result<BookingReceipt>?>(null);

useEffect(() {
  final current = bookingResult.value;
  if (current == null || current.isOk) return null;

  switch (current) {
    case Err(:final e) when e is BookingFailureInvalidRequest:
      showMessage('Please check the guest information.');
    case Err(:final e) when e is BookingFailureRoomNotFound:
      showMessage('This room is no longer available.');
    case Err(:final e) when e is BookingFailureRoomAlreadyBooked:
      showMessage('The room was just booked by someone else.');
    case Err():
      showMessage('Something went wrong. Please try again.');
    case Ok():
      break;
  }

  return null;
}, [bookingResult.value]);

That keeps failure explicit all the way to the widget layer. Nothing is thrown here unless you choose to throw.

2. Connect a `Result` API to Riverpod

The same flow also fits Riverpod. The main difference is that AsyncValue.guard expects a throwing callback, so this is where orThrow becomes useful.

final bookingProvider =
    AsyncNotifierProvider.autoDispose<BookingNotifier, BookingReceipt?>(
      BookingNotifier.new,
    );

class BookingNotifier extends AsyncNotifier<BookingReceipt?> {
  @override
  BookingReceipt? build() => null;

  FutureResult<BookingReceipt> _reserveRoom(BookingForm form) => $doAsync(() async {
    final guestName = Result.fromNullable(form.guestName).flatMap(requireNotBlank).$;
    final guestId = Result.fromNullable(form.guestId).flatMap(verifyGuestIdFormat).$;

    final response = await Result.future(
      dio.post('/rooms/reserve', data: {
        'guestName': guestName,
        'guestId': guestId,
        'roomId': form.roomId,
      }),
    ).mapErr((error, _) => switch (error) {
      HttpException(statusCode: 400) => const BookingFailure.invalidRequest(),
      HttpException(statusCode: 404) => const BookingFailure.roomNotFound(),
      HttpException(statusCode: 409) => const BookingFailure.roomAlreadyBooked(),
      _ => BookingFailure.unknown(error),
    }).$;

    return Result.jsonMap(BookingReceipt.fromJson)(response.data).$;
  });

  Future<void> submit(BookingForm form) async {
    state = const AsyncValue.loading();

    state = await AsyncValue.guard(
      () => _reserveRoom(form).orThrow,
    );
  }
}

Inside $doAsync, .$ keeps the workflow linear. Outside $doAsync, .orThrow is the bridge into Riverpod's exception-based API. That makes the boundary clear: typed Result inside your app logic, thrown exceptions only where the framework asks for them. The original stack trace is preserved, so debugging still points back to the real failure site.

In the widget, you pattern match on Riverpod's AsyncValue instead of storing Result directly:

switch (ref.watch(bookingProvider)) {
  case AsyncData(:final value) when value != null:
    return SuccessView(receipt: value);
  case AsyncError(:final error) when error is BookingFailureInvalidRequest:
    return const ErrorView('Please check the guest information.');
  case AsyncError(:final error) when error is BookingFailureRoomNotFound:
    return const ErrorView('This room is no longer available.');
  case AsyncError(:final error) when error is BookingFailureRoomAlreadyBooked:
    return const ErrorView('The room was already booked.');
  case AsyncError():
    return const ErrorView('Something went wrong.');
  default:
    return const LoadingView();
}

The connection is simple:

Use .$ inside $doAsync to keep multi-step fallible code readable.
Use mapErr(...) and Result.jsonMap(...) to translate and decode safely.
Use orThrow only at the Riverpod boundary, where AsyncValue.guard expects exceptions.

In practice, this split works well: keep domain and data layers explicit with Result, then convert only where a framework requires exceptions.

Summary

Result is not about banning exceptions. It is about making expected failure visible, composable, and easier to reason about.

With Dart 3 features like sealed classes and patterns, this style feels much more natural than it used to. neverthrow_dart adds the small utilities that make the pattern practical in Flutter: do-style composition, JSON helpers, async support, and framework-boundary escape hatches like orThrow.

If you want error handling to be more explicit without making the code harder to read, Result is worth serious consideration, and neverthrow_dart is a focused way to apply that pattern in Dart.

Try now:
https://pub.dev/packages/neverthrow_dart

Why FlatMap Isn’t Ideal for Go Error Handling — A Case for go-opera

ColaFanta — Sat, 11 Apr 2026 15:53:15 +0000

Many Go libraries borrow ideas from functional programming, usually Either, Result, and Option, to make error handling less repetitive. The promise is simple: wrap failure in a result type, use FlatMap, and stop writing if err != nil after every line.

Why `FlatMap`

To be fair, FlatMap works very well in languages where composition syntax is light.

Let's look at a scenario: get a guest name out of nested response data, then create a booking and assign a room.

In TypeScript, that stays compact:

const bookFromResponse = (response: Response): E.Either<Error, string> =>
  pipe(
    E.fromNullable(new Error('missing guest name'))(
      response.data?.list?.[1]?.user?.name,
    ),
    E.flatMap(createBooking),
    E.flatMap((booking) => assignRoom(booking, 'Suite')),
  )

This reads well. The pipeline stays flat, each callback is small, and the syntax does not fight the idea.

TypeScript also gives you lightweight tools for ordinary data access. Optional chaining like response.data?.["list"]?.[1]?.user?.name stays small and readable.

In Go, only half of that advantage survives. In a FlatMap-first style, the same idea becomes much heavier:

bookFromResponse := func(response Response) either.Either[error, string] {
    return function.Pipe3(
        fromOption(func() error { return errors.New("missing guest name") })(
            optionPipe(
                maybeNil(response.Data),
                flatMap(func(data ResponseData) Option[ListItem] {
                    return at(data.List, 1)
                }),
                flatMap(func(item ListItem) Option[User] {
                    return maybeNil(item.User)
                }),
                flatMap(func(user User) Option[string] {
                    return maybeEmpty(user.Name)
                }),
            ),
        ),
        either.Chain(func(name string) either.Either[error, Booking] {
            return createBooking(name)
        }),
        either.Chain(func(booking Booking) either.Either[error, string] {
            return assignRoom(booking, "Suite")
        }),
    )
}

FlatMap is good at one thing: propagating failure. If one step fails, the rest of the pipeline is skipped. That part works.

But error propagation is not the whole problem in ordinary Go code. We also want to read the happy path quickly and understand the function without decoding a stack of callbacks.

That is where FlatMap stops helping.

TypeScript can write a => next(a). Go has to write func(a A) Result[B] { return next(a) }.
TypeScript can do optional chaining. Go has to spell the same traversal out through helper functions and repeated flatMap calls just to reach a nested value.

FlatMap removes explicit if err != nil, but it does not remove boilerplate in Go. In a language without arrow functions, moving the boilerplate into callback syntax is not a small trade.

In Go, function literals are visually heavy, and their return types must be written out every time. The code starts to describe the composition mechanism more than the business logic.

This is exactly why direct style is better.

With go-opera, the same flow stays close to ordinary Go:

bookFromResponse := func(response Response) opera.Result[string] {
    return opera.Do(func() string {
        data := opera.MaybeNilPtr(response.Data).Yield()
        item := opera.TryAt(data.List, 1).Yield()
        user := opera.MaybeNilPtr(item.User).Yield()
        name := opera.MaybeEmpty(user.Name).Yield()
        booking := createBooking(name).Yield()
        return assignRoom(booking, "Suite").Yield()
    })
}

This gives you the same fail-fast behavior, but it does something FlatMap does not do well in Go: it keeps the success path linear.

Why Direct Style Is Better

The advantage of direct style is straightforward.

You do not have to wrap tiny operations into separate func(...) ... {} blocks just to keep the chain moving.
Most Go developers are trained to understand a sequence of statements quickly. Direct style preserves that strength instead of hiding it behind combinators and explicit callback signatures.
It is easier to debug. You can put a breakpoint on each line, inspect each value, and follow the happy path like any other function.

This is the core argument for go-opera: it keeps the monadic fail-fast behavior, but presents it in a form that matches how Go code is naturally written and read.

FlatMap is still useful. It is just not the best primary interface for day-to-day Go error handling. In Go, the main problem is not only propagating failure, but also expressing dependent work without turning each small step into another full function literal.

Summary

FlatMap solves error propagation. It does not solve readability in Go.

Direct style solves that better.

Once a function needs several dependent steps, a FlatMap-first style starts adding full func(...) ReturnType { ... } blocks and composition scaffolding. The code still works, but the boilerplate has only changed shape.

go-opera keeps the same fail-fast semantics while letting the success path stay flat, named, and local. That is why direct style is a better fit for Go.

Effective error handling in Go with Rust-like Result and "?"

ColaFanta — Sat, 04 Apr 2026 11:32:56 +0000

Error handling in Go has been debated for years. Many developers appreciate the explicit and imperative style of if err != nil, and there is real value in that clarity. But that same style also limits how expressive code can be. As the control flow becomes more complex, the amount of boilerplate grows quickly, and the actual business logic gets buried under repetitive error checks.

TLDR:
A Rust-like "?" style error handling is possible with go-opera:

func createOrder(userID string, amount int) opera.Result[string] {
    return opera.Do(func() string {
        user := findUser(userID).Yield() // Yield in like "?" in Rust
        account := loadAccount(user.AccountID).Yield()
        validateBalance(account, amount).Yield()
        paymentID := charge(account, amount).Yield()
        return fmt.Sprintf("order created for %s with payment %s", user.Name, paymentID)
    })
}

The goal of go-opera is simple and straight forward: keep Go's explicitness, but reduce the friction.

Common pitfalls

Redundant empty value

When a function fails, Go still expects you to return an empty value together with the error:

func loadUser(id string) (User, error) {
    if id == "" {
        return User{}, errors.New("empty id")
    }
    return User{ID: id}, nil
}

The zero value is usually just filler. It adds noise, not meaning.

Unable to use return value directly

Go supports multiple return values, but it does not let you pass them directly as arguments to another function.

func parsePort() (int, error) {
    return strconv.Atoi("8080")
}

func openServer(port int) error {
    return nil
}

func main() {
    // this does not compile
    openServer(parsePort())
}

You always have to unpack first. That hurts composition.

Error name collision

Once a function grows, repeated err, err2, err3, or shadowed err variables make the code harder to read and maintain:

func tooManyErrors() error {
    val1, err1 := errFunc1()
    if err1 != nil {
        return fmt.Errorf("step 1 failed: %w", err1)
    }

    val2, err2 := errFunc2(val1)
    if err2 != nil {
        return fmt.Errorf("step 2 failed: %w", err2)
    }

    val3, err3 := errFunc3(val2)
    if err3 != nil {
        return fmt.Errorf("step 3 failed: %w", err3)
    }

    if err4 := errFunc4(val3); err4 != nil {
        return fmt.Errorf("step 4 failed: %w", err4)
    }

    return nil
}

Shadowing err has a similar problem:

func process() error {
    data, err := readFile()
    if err != nil {
        return err
    }

    if err := validate(data); err != nil {
        return err
    }

    if err := save(data); err != nil {
        return err
    }

    return nil
}

This is idiomatic, but not cheap to read. As steps grow, the function becomes error bookkeeping.

Introducing `go-opera`

go-opera is a small Go package that brings a more expressive error handling model through Result, Option, and Do notation.

The idea is inspired by patterns from Rust and functional programming libraries like EffectTS, adapted to fit Go instead of fighting it. The goal is not to hide errors but to make error propagation easier to read, easier to compose, and less repetitive.

At the center of the package is Result[T], which represents either a successful value or an error.

func parsePort(raw string) opera.Result[int] {
    port, err := strconv.Atoi(raw)
    if err != nil {
        return opera.Err[int](err)
    }
    return opera.Ok(port)
}

res := parsePort("42").OrPanic()

The real benefit appears when your own functions return Result[T] and compose with opera.Do(...).

Accumulative error handling with `Do`, Easy function chain with `Yield`

In conventional Go, each step must unwrap (value, error) and then wrap the error again to return it. If your own functions return Result[T], opera.Do lets you compose them directly and propagate failures to the exact point where you want to handle them.

func createOrder(userID string, amount int) opera.Result[string] {
    return opera.Do(func() string {
        user := findUser(userID).Yield()
        account := loadAccount(user.AccountID).Yield()
        validateBalance(account, amount).Yield()
        paymentID := charge(account, amount).Yield()
        return fmt.Sprintf("order created for %s with payment %s", user.Name, paymentID)
    })
}

Yield is like ? in Rust and yield* in EffectTS. Every .Yield() means: “give me the value, or stop here and bubble the error out of the surrounding Do block.”

Without Yield, you would need temporary variables and an if err != nil after every single step. With Yield, each step can feed the next one directly, so the code reads more like a pipeline than a chain of guards.

That keeps the happy path linear. You read the logic from top to bottom, and error propagation happens automatically.

Error recovery with `Catch`

Not every error should abort the whole flow. Sometimes you want a sensible fallback.

go-opera supports this with Catch and CatchIs.

func findDisplayName(userID string) opera.Result[string] {
    return opera.Do(func() string {
        user := loadUser(userID).Yield()
        return user.DisplayName
    }).
        Catch(func(err error) opera.Result[string] {
            if errors.Is(err, ErrUserNotFound) {
                return opera.Ok("guest")
            }
            return opera.Err[string](err)
        })
}

If you only need to recover from a known error with a fixed fallback value, CatchIs is even shorter:

func checkLogin(user, password string) opera.Result[bool] {
    return opera.Do(func() bool {
        u := repo.FindUser(user).Yield()
        verifyPassword(u.Password, password).Yield()
        return true
    }).
        CatchIs(ErrUserNotFound, false).
        CatchIs(bcrypt.ErrMismatchedHashAndPassword, false)
}

This keeps recovery close to the boundary where you actually want to recover, instead of scattering special-case checks through the whole function body.

Compatible with existing Go conventions

One thing I care about is that go-opera works with normal Go code instead of forcing you into a closed ecosystem.

In other words, I prefer writing internal application code with Result[T], and only switching back to (value, error) when I need to integrate with conventional Go APIs.

If you already have a function that returns (T, error), you can wrap it with Try:

res := opera.Try(os.ReadFile("config.json"))

If you want to go back to normal Go style at the boundary of your function, call Get:

func loadMessage() ([]byte, error) {
    return opera.Do(func() []byte {
        body := opera.Try(os.ReadFile("message.txt")).Yield()
        return bytes.TrimSpace(body)
    }).Get()
}

So the migration path is incremental. You can adopt Result only where it helps, and still expose the usual (value, error) API to the rest of your application.

Before and after

Example 1: straight-line business logic

Before:

func register(email string) (User, error) {
    validatedEmail, err := validateEmail(email)
    if err != nil {
        return User{}, fmt.Errorf("validate email: %w", err)
    }

    existingUser, err := findUserByEmail(validatedEmail)
    if err != nil {
        if !errors.Is(err, ErrUserNotFound) {
            return User{}, fmt.Errorf("check existing email: %w", err)
        }
    } else {
        if existingUser.ID != "" {
            return User{}, fmt.Errorf("email already registered: %w", ErrEmailTaken)
        }
    }

    createdUser, err := createUser(validatedEmail)
    if err != nil {
        return User{}, fmt.Errorf("create user: %w", err)
    }

    if err := sendWelcomeEmail(createdUser); err != nil {
        return User{}, fmt.Errorf("send welcome email: %w", err)
    }

    return createdUser, nil
}

After:

func register(email string) opera.Result[User] {
    return opera.Do(func() User {
        validated := validateEmail(email).Yield()
        ensureEmailAvailable(validated).Yield()
        created := createUser(validated).Yield()
        sendWelcomeEmail(created).Yield()
        return created
    })
}

The business flow is easier to see because the function is no longer dominated by repetitive branching.

Example 2: handling a recoverable error

Before:

func checkLogin(user, password string) (bool, error) {
    u, err := repo.FindUser(user)
    if err != nil {
        if errors.Is(err, ErrUserNotFound) {
            return false, nil
        }
        return false, fmt.Errorf("find user: %w", err)
    }

    if u.Locked {
        return false, nil
    }

    if err := bcrypt.CompareHashAndPassword([]byte(u.Password), []byte(password)); err != nil {
        if errors.Is(err, bcrypt.ErrMismatchedHashAndPassword) {
            return false, nil
        }
        return false, fmt.Errorf("verify password: %w", err)
    }

    if err := markLastLogin(u.ID); err != nil {
        return false, fmt.Errorf("update last login: %w", err)
    }

    if !u.Active {
        return false, nil
    }

    return true, nil
}

After:

func checkLogin(user, password string) opera.Result[bool] {
    return opera.Do(func() bool {
        u := repo.FindUser(user).Yield()
        ensureLoginAllowed(u).Yield()
        verifyPassword(u.Password, password).Yield()
        markLastLogin(u.ID).Yield()
        return true
    }).
        CatchIs(ErrUserNotFound, false).
        CatchIs(ErrUserLocked, false).
        CatchIs(bcrypt.ErrMismatchedHashAndPassword, false)
}

This version makes the success path obvious, while still keeping error recovery explicit.

Conclusion

Go's traditional error handling is explicit, simple, and proven. But in larger flows, it also creates friction: placeholder zero values, repetitive branching, and a lot of code that exists only to move errors around.

go-opera is my attempt to keep the good part of Go's error model while reducing that friction. With Result, Do, Yield, and Catch, you can keep most of your internal code in a composable form and only convert back to (value, error) when you need to integrate with conventional Go APIs.

It is not meant to replace every if err != nil in Go. It is a tool for the parts of your code where composition and readability matter most.

Give it a try:

https://github.com/colafanta/go-opera

Forem: ColaFanta

Go Admin Dashboard for E-Commerce with HTMX, Templ UI, and GORM - Part 1

Prerequisites

Set up the server

Import UI components

Make a landing page

Make the dashboard layout

A Fiber adapter for templ

Wire things up with HTMX

Part 1 Summary

Async/Await-like pattern in Go to make concurrency simple, robust, less boilerplate

Goroutine

Async/Await

Better Async/Await

Introducing go-opera

Better encapsulation

No need for manual done signal or WaitGroup

Better error handling

Structured concurrency

AwaitAll

AwaitAllSettled

AwaitFirst

AwaitZip, AwaitZip3 ... AwaitZip9

Flutter Error Handling with Result, introducing neverthrow_dart

Flutter Error Handling with Result in neverthrow_dart

Why Result is useful

Why neverthrow_dart

1. Naive Result types often lose value semantics

2. Without error propagation, you escape try/catch only to land in match hell

3. Some libraries keep the error but lose the stack trace

4. Splitting sync and async results creates a conversion tax

5. Result<T, E> is elegant in theory, but awkward in Dart

Real-world example of neverthrow_dart

1. Compose multiple fallible steps with $doAsync

2. Connect a Result API to Riverpod

Summary

Why FlatMap Isn’t Ideal for Go Error Handling — A Case for go-opera

Why FlatMap

Why Direct Style Is Better

Summary

Effective error handling in Go with Rust-like Result and "?"

Common pitfalls

Redundant empty value

Unable to use return value directly

Error name collision

Introducing go-opera

Accumulative error handling with Do, Easy function chain with Yield

Error recovery with Catch

Compatible with existing Go conventions

Before and after

Example 1: straight-line business logic

Example 2: handling a recoverable error

Conclusion

A `Fiber` adapter for `templ`

No need for manual `done` signal or `WaitGroup`

`AwaitAll`

`AwaitAllSettled`

`AwaitFirst`

`AwaitZip`, `AwaitZip3` ... `AwaitZip9`

Flutter Error Handling with `Result` in `neverthrow_dart`

Why `Result` is useful

Why `neverthrow_dart`

1. Naive `Result` types often lose value semantics

2. Without error propagation, you escape `try/catch` only to land in match hell

5. `Result<T, E>` is elegant in theory, but awkward in Dart

Real-world example of `neverthrow_dart`

1. Compose multiple fallible steps with `$doAsync`

2. Connect a `Result` API to Riverpod

Why `FlatMap`

Introducing `go-opera`

Accumulative error handling with `Do`, Easy function chain with `Yield`

Error recovery with `Catch`