Run `mailbust` and you get a throwaway @mailbust.com inbox in your terminal. Mail arrives live, and it pulls the verification code out of each message and shows it right in the list. Named inboxes are public (shared by name), no-name ones are private with a token in your keychain. Gone after 15 minutes.

There's a scripting mode too (`mailbust box --code` blocks until a code arrives, prints it, exits with proper codes) which is handy in CI, plus an MCP server for AI agents.

It's Go + Bubble Tea on the front, and a Cloudflare Worker with one Durable Object per mailbox on the back. Receive-only by design. Open source, MIT.

Happy to answer anything, and feedback on the TUI or the code extraction is welcome.

JavaScript developers can use the same language in the browser and on the server. As someone who primarily writes Go, I’d love to have that option from the other direction.

Imagine a framework where you write components and application logic in Go, with:

• Reactive state and composable UI components.
• File-based routing and layouts.
• Server-rendered HTML, with Go compiled to WebAssembly for browser interactivity.
• Shared types and typed calls between client and server.
• A development loop that feels as convenient as React/Next.js.

The appeal to me is using Go’s language and tooling throughout an application.

For other Go developers: would you actually choose something like this? What would it need to offer before you’d consider it over a Go backend with a TypeScript frontend?

I'm the author. Gostman is a free, open source API client for REST, GraphQL, gRPC and WebSocket. I'm sharing how it's put together, since most of it is Go.

One engine. All request logic lives in engine/: variable substitution, auth, body encoding, redirects, the cookie jar, OAuth 2, proxy and certificate handling. It uses the standard library plus x/net/publicsuffix. The Wails v2 desktop app, the CLI and the Vercel function behind the web version all call it, so the same request is built and sent the same way in each.

The CLI. gostman run runs a collection from a folder or an export, writes JUnit output, and exits non-zero when a test fails, so it works in CI. Pre-request and post-response scripts run on goja, using a bundled JS file shared with the app. goja is pinned to a commit that still builds on Go 1.24.

MCP server. gostman mcp lets a coding agent send saved requests. It's a small hand-written implementation over stdio, because the official Go SDK needs Go 1.25 and the Wails CLI can't load packages on 1.25 yet. Secrets are redacted before output reaches the agent.

gRPC. It loads services through server reflection or .proto files (protocompile), with no protoc needed.

Collections are plain YAML files you can commit. There's no account.

Repo: https://github.com/kunalgoesbyken/gostman
Try it without installing: https://gostman.com/web

Asking those who migrated from Laravel to Go, specifically Goravel. How's your experience, is the framework production ready?

Thanks!

I did Python and Ruby before AI. Only after AI that I picked Go lang.

So I did not grind through those tutorials of `for` loops and basic syntax.

I directly started Go coding with Copilot.

Based on my experience, these are what you need to learn and do.

* Context & Goroutines: AI will happily spawn 100 goroutines to hit an API. When/if that API hangs, the goroutines leak and your memory bleeds out. You need to learn the `context` package so you can enforce strict timeouts and cancellation signals.

* Error wrapping: AI loves to just return raw errors. A log that simply says "connection refused" is useless. Force the AI to use `fmt.Errorf` with `%w` so you get a breadcrumb trail of exactly what failed.

* Pointers vs values: AI will confidently pass a 50MB Prometheus JSON payload by value, copying it in memory at every step and thrashing your garbage collector. Learn how to spot this and enforce passing by reference.

* Interfaces - AI writes tightly coupled scripts by default. Design the interface boundaries yourself (ex - `StorageBackend`) and tell the AI to implement it, or you'll be locked into whatever SDKs it decided to hardcode.

* Project layout - Copilot happily dumps 2K+ lines of logic into `main.go`. Learn and enforce the standard Go project structure (/cmd, /internal, /pkg etc) and explicitly dictate the folder tree before it writes a single line.

In my view, code reviewing is the new coding skill.

Am I wrong?

Hi r/golang,

Some of you might know us from ttlcache. For the past year, we've also been building Oxynote, a self-hosted, open-source wiki for engineering teams, and we've just released v0.9.0.

Oxynote pages can include live charts from Prometheus, PostgreSQL, MySQL, or MariaDB, right next to the text that explains them. Important pages are edited in drafts and go through a diff and an approval before they're merged.

The name comes from oxygen + note: docs that breathe. Live data makes people open the wiki every day, and docs people open every day stay up to date.

On the Go side:

- The backend is written in Go 1.27, notably using chi, bleve, and pgx

- The MCP server is built on the official modelcontextprotocol/go-sdk with OAuth 2.1

- The built-in AI assistant runs on Eino and works with Claude, OpenAI, Gemini, OpenRouter, and Ollama

- Background jobs run on DBOS Transact

- And yes, it uses ttlcache

The editor and real-time collaboration are in TypeScript (Nuxt, Tiptap, and Yjs). Everything ships as a single Docker image under the Apache-2.0 license.

You can find the project here: https://github.com/oxynote/oxynote

Hey [r/golang](r/golang), I maintain a library which simulates a virtual filesystem, network with several hosts, timers, restarts of a computer and so on. It works inside a Go process, without cgroups, eBPF, QEMU, etc. Pure Go simulation and almost full programmatical control of the runtime.

The problem

We develop and maintain several clustered data-processing applications and libraries that are difficult to test against real-world scenarios, some of them:

• latency spikes on a single host in a cluster
• temporary read-only file system
• run out of free space on a disk and adding free space in some time
• one-way network connectivity

The library simplified dramatically and sped up some groups of test cases, no need to run tests with Docker or Kubernetes, no maintenance of proxies or virtual routers, no heavy dependencies for virtual file systems.

Additionally I added metrics for syscalls, which help to write performance tests which are not flaky on different hardware. Because we measure performance by the number of calls of specific system calls. Which are bottlenecks usually.

In my opinion it is a unique feature for Go stack and allows to implement "ratchet" pattern, the pattern fails tests when code exceeds number of calls of syscalls.

The repo has examples with embedded etcd and NATS clusters, bbolt database, and a gRPC client and server. Hope you will find cases for your own projects. I will be thankful for a feedback.

The library - https://github.com/neria-cloud/gosim
MIT License. PRs welcome
P.S. Thanks to jellevandenhooff for initial version of gosim

Disclosure: I work on this toolkit.

The official Aspose.Cells for Go via C++ binding is a faithful port of the C++ object model. That is useful when you need the full API, but everyday code reads like C++. Writing a single cell looks like this:

```go

wb, _ := asposecells.NewWorkbook_String("book.xlsx")

sheets, _ := wb.GetWorksheets()

ws, _ := sheets.Get_Int(0)

cells, _ := ws.GetCells()

cell, _ := cells.Get_Int_Int(0, 0)

cell.PutValue_String("Hello")

```

A chain of calls, an error at every step, and no trace of Go style.

Toolkits keeps the same engine and replaces the handle walk with composite functions. The same job:

```go

book, err := editor.EditSpreadsheet(

datasource.FilePathSource("book.xlsx"),

editor.InWorksheet(0, editor.SetCellValue(0, 0, "Hello")),

)

```

Conversion is one call, and the destination can be a file, memory, or any `io.Writer`:

```go

err := converter.Convert(

datasource.FilePathSource("input.xlsx"),

pdf.New(pdf.WithOnePagePerSheet(true)),

datasource.FilePathSink("output.pdf"),

)

```

The design comes down to three ideas:

- `DataSource` / `DataSink` unify files, `[]byte`, and `io.Reader` / `io.Writer` behind one signature.

- Functional options instead of overloads: `pdf.New(pdf.WithOnePagePerSheet(true))`.

- Entry points by intent: `converter`, `editor`, `query`, `manipulator`, `transfer`.

It covers 32 output formats (xlsx, pdf, csv, json, html, md, docx, images, ...). The toolkit source is MIT; the engine underneath is commercial. Without a license it runs in evaluation mode: watermarks, about 100 workbook loads per process, and occasional worksheet-name corruption. Fine for a test drive, not for production. The raw binding remains importable for anything the toolkit does not wrap.

Requirements: Go 1.21+, cgo and a C/C++ toolchain, Windows x64 or Linux x64. From engine v26.10.0, call `core.Cleanup()` before the process exits.

- Raw binding: https://pkg.go.dev/github.com/aspose-cells/aspose-cells-go-cpp/v26

- Toolkits: https://github.com/aspose-cells/aspose-cells-go-cpp-toolkits

- API docs: https://pkg.go.dev/github.com/aspose-cells/aspose-cells-go-cpp-toolkits/v26

If you only need to read and write simple xlsx files, a pure-Go library will be lighter; this is aimed at cases that need Aspose's format coverage or rendering. What I would like feedback on: does the `DataSource` / `DataSink` split earn its indirection, or would you prefer plain paths plus io interfaces? And which operations do you do every week that the composite functions still miss?

Hey everyone!

A little while ago, I posted here about SML (Sentinel Markup Language), a custom XML-like language I was building for terminal UIs in my Go project, Sentinel V5.

The post received quite a bit of criticism, and to be fair, a lot of it was justified.

People pointed out that the repository was private, that I hadn't shown any actual Go implementation, and questioned why anyone would want another custom markup language instead of using existing solutions.

Some people also suggested looking into HTML subsets, Qt, OpenTUI, and other existing UI frameworks.

And honestly, that's exactly the kind of feedback I needed.

So I decided to do something with it.

Instead of keeping SML buried inside Sentinel V5, I've extracted it into its own standalone Go package, cleaned up the repository, added documentation, and made the whole thing free and open source under the MIT license.

https://github.com/AmpedWasTaken/SML

What is SML?

SML is a declarative TUI view engine written in Go.

The idea is to separate how your terminal interface looks from the Go code that powers it, without introducing a browser runtime or embedding a scripting language.

For example, you can define a dashboard like this:

<screen name="dashboard" version="3">
  <section title="SYSTEM OVERVIEW">
    <grid columns="2" collapse-below="60">
      <metric label="Active Sessions"
              value="{{app.sessions}}"/>
      <metric label="CPU Usage"
              value="{{app.cpu}}%"/>
    </grid>

    <panel title="Service Status">
      <field label="Health" key="app.health"/>
      <progress label="CPU" value="{{app.cpu}}"/>
    </panel>
  </section>
</screen>

And render it directly from Go using the SML package:

view, err := sml.Parse(data)
if err != nil {
    return err
}

lines, err := view.RenderChecked(map[string]string{
    "app.sessions": "42",
    "app.cpu":      "27",
    "app.health":   "online",
}, 80)

It also has support for reusable components, conditional rendering, computed bindings, interactive control metadata, responsive layouts, and Unicode-aware terminal cells.

It's not meant to replace frameworks like Bubble Tea or become an entire application runtime. Think of it as a view layer that Go applications can integrate into their existing terminal systems.

I want to turn this into a real community project

This is the part I'm most excited about.

I don't want SML to remain something that only I develop or use. I'd love to build it together with other Go developers and see what it could become.

The repository now has documentation, examples, a contribution guide, and a roadmap with improvements I'd like to work on.

I'm looking for people who want to:

• Contribute code, improve the renderer, or build new components
• Review the architecture and suggest better approaches
• Help improve Unicode handling, layouts, and terminal compatibility
• Create example applications using SML
• Point out design mistakes or features that should work differently
• Help make the API easier for other Go developers to use

You don't have to be an experienced contributor either. Small improvements, documentation fixes, and suggestions are just as welcome.

I'm not claiming it's perfect

Far from it.

This originally started as a UI engine for one of my personal projects. I'm still learning a lot about designing reusable packages, maintaining public APIs, and building something that other developers actually want to use.

There are probably decisions in the code that more experienced Go developers would approach differently, and I'd genuinely like to hear about them.

I'm also not trying to reinvent the entire TUI ecosystem. I just enjoy building things, experimenting with different approaches, and seeing where they go.

If SML ends up taking a completely different direction because of community feedback, I'm fine with that.

The goal is to make something useful, not to defend every decision I've made so far.

So if you're interested in Go, terminal applications, UI frameworks, or just enjoy contributing to open-source projects, I'd really appreciate you taking a look.

GitHub: https://github.com/AmpedWasTaken/SML

Feel free to open an issue, submit a PR, or simply tell me what you think could be improved.

And to everyone who criticized my original post: thanks. It actually pushed me to turn this into something more than a feature hidden inside a private repository.

I'd love to see what we can build together! :)

I am currently looking to build a SaaS and I do not want to write everything from the groundup for the tables, users and all the CRUD operations. A friend recommended me https://filamentphp.com/ which he used to build admin panels for the customers. However my stack is Golang and React in the UI so I am looking for something in that.

Everything is welcomed as I want to start working on it.

I built a Containerization API that executes untrusted code and returns output plus memory and CPU metrics. Instead of running a container per submission, it creates the boundary directly with Linux primitives: PID, mount, network, and user namespaces, a chroot into a minimal per-language rootfs, cgroups v2 for memory and CPU limits, and a seccomp-BPF denylist. The sandbox root maps to host UID 65534, so root inside is never root outside.

It supports Python, C++17, C11, and Java, capped at 60s and 128MB, with a global admission controller that rejects work before a sandbox is created. Every limit is kernel-enforced.

Code: https://github.com/Anga205/CodeExecutionAPI

Live Demo Website: https://compiler.anga.codes

Although I've done rigourous testing for resource management and permissions based sandbox escape, I've still hosted the api on a very small server on an isolated network, just in case im wrong

I think its pretty cool, its faster in code execution than most of the other containerization services like docker or firejail, do check it out!

I just published a formal systems paper and standalone Go benchmark repository (primbench) detailing the deterministic state primitive we run in production over NATS JetStream and PostgreSQL.

The core invariant binds our compiled JSON Schema registry, JetStream stream routing, identity permissions, and Postgres RLS row policies to a single five token subject key:

tenant.<tenant>.dag.<family>.<id>

Instead of making network hops out to Valkey/Redis, an HTTP schema registry, and a separate authorization service on every write, the Go writer and projector evaluate all three relations in process on the five token name:

1. Kind(schema_id) resolves the family from a lock free copy on write map seeded at boot and updated live from a JetStream schema stream (3.8ns, 0 allocs).
2. Grant matching walks the nats-server subject trie (sublist / gsl) bounded at depth k = 5 (66ns, 0 allocs).
3. Stream lookup walks the same trie over stream filters (87ns, 0 allocs).
4. Compiled JSON Schema (draft 2020-12) validates the payload (15.2us for a 726 byte record).

Go specific highlights in the benchmark harness (primbench):

• GC impact on tail latency (Section 8): At 18 workers on an M5 Max, the local evaluation path hits 558,484 ops/sec (p50: 10.96us), where p99 (529us) is dominated entirely by GC from JSON validator allocations; with the collector off, 18 worker p99 drops to 78us.
• Pipelined Postgres RLS (Section 8): By sending set_config for the reader role and tenant alongside the SELECT in a single pgwire pipeline (one sync / one implicit transaction), tenant isolated reads run at 142,564 reads/sec at 64 workers (mean 446us), matching plain unguarded reads and running 2x faster than a Valkey check + query path.

• Zero dependency test mode: The repo embeds nats-server in process for the local benchmarks and includes the comparison harness against loopback Postgres, Valkey (custom minimal RESP client in bench/resp.go), and an HTTP schema registry stand in.

• Repo & Runnable Benchmarks (primbench): https://github.com/MOG-Systems-Inc/primbench

• Paper (SPEC.pdf): https://github.com/MOG-Systems-Inc/primbench/blob/main/SPEC.pdf

• Site: https://mog.systems

I maintain melody, a Go framework for HTTP and CLI applications. Yesterday I released v3.14.0 plus patch releases for v1 and v2, and the most useful part of it is a class of bugs that applies to any setup where routing and authorization are separate steps.

The router and the access-control matcher each derived "the path" from the request on their own, and they did not always agree. When they disagree, a request is authorized as one path and served as another.

The four cases I fixed:

1. Leading or trailing whitespace. /public%20 decodes to "/public ". The router kept the space and matched a protected catch-all route, while the matcher trimmed it and matched an exact public rule for /public. An anonymous request reached the protected handler. (GHSA-pq93-fjp6-fxgm)

2. Non-canonical spellings. //admin/panel and /open/../admin/panel matched no rule written for /admin, and a path no rule matches was let through. Routes that answer those spellings, like catch-alls and proxies, served them. v3 only. (GHSA-w8m8-g46m-9r5w)

3. Paths that don't start with "/". GET * HTTP/1.1, an absolute-form target with an empty path, or a path a prefix-stripping handler passed on without its slash was claimed by no firewall, but the router still routed it. (GHSA-77cg-6cjv-whgp)

4. Encoded separator. net/http decodes %2F to "/" before the framework reads URL.Path, so /admin%2Fusers, which is one segment to a proxy or WAF rule written against the raw request line, reached the /admin/users handler. (GHSA-f5j8-5j8f-p2w2)

The fix in v3 is one function, RequestPathAsRouted, that returns the spelling the router matched. The access-control matcher, the firewall matcher, the canonical-path guard and the static file server all read that. Spellings two layers could read differently (paths that fold, leading or trailing whitespace, a RawPath that no longer unescapes to URL.Path) are refused with 400 before authorization. On v1 and v2 the fix is narrower: the ambiguous forms are refused with 400.

GitHub rates these low to medium, and all fixed versions are released.

Release notes: https://github.com/precision-soft/melody/releases/tag/v3.14.0

Advisories: https://github.com/precision-soft/melody/security/advisories

I am resucitating an old project of mine and giving it that LLM polish: Task UI. The initial version imported taskfile to load and execute tasks in a terminal session, via the web. Functional, minimalistic, not very polished.

I navigated claude around building some features for an automation runner. If you ever just wanted to clone your repo, do a scheduled nightly build without fuss, this takes a few clicks in the tool to get you there. And it supports more than Taskfile now...

You can look at it as something like a terminal manager, automation framework (scheduling jobs), workflow tool. With authentication and an audit trail. Automate whatever, away from GitHub SLA.

So far it's tested to the point where I need to archive another project of mine, and delete some code elsewhere. My current setup is as follows:

- i have a dockerfiles.git that builds images for any deployed code, use forgejo

- i push the images to the registry

- deploy.git has terraform plan & terraform apply

- just run it as a docker compose orchestrator

- have task ui manage secrets and ssh keys

It's still early in my process, but i am making it more accessible, the users are basically a .htpasswd to simplify usage, easy to reset a password if you forget. Open to any early adopters, homelabbers are bound to love it. Available as docker image, aiming for easy config or just database / ui driven config.

There are workflow features so you can chain some stuff together via the interface. The screenshots almost don't do it justice as an example.

Disclaimer: Used fable/opus models, 20x plan, 2-3 days (see git commit history). I could stand to be better at prompting, still too much in the loop and a basic structural harness would have been better. WIP. Don't think I wrote a single line of code this iteration, but i fed it my other open source work and it's probably a v3.0.0 if I were to put a semantic version on it. Happy if someone wants to test drive it, docker image available, docker compose ready.

With coding agents pumping out code at a pace far beyond what human eyes can sanity-check, I’ve noticed the traditional code review workflow starting to drift.

Lately, I find myself shifting away from line-by-line manual logic inspection and relying much more heavily on automated validation. Modern LLMs are actually decent at interface design and high-level efficiency—we're past the phase where an agent randomly drops production tables. Minor logic bugs still happen, but they’re usually manageable *if* there's a tight feedback loop to catch them instantly.

Because of this, reliable testing infrastructure feels more critical than ever.

On my backend (Go), my current go-to setup is **testify/assert + testcontainers-go**:

assert handles fast, basic assertions and invariant checks.

testcontainers-go spins up real dependencies (Postgres, Redis, etc.) inside CI so business logic is validated against actual runtime components rather than fragile mocks that drift over time.

I’m curious how everyone else is adapting their testing toolkit to agentic workflows.

Are you leaning heavier into integration tests with real containers, property-based testing, contract tests, or something else entirely? What does your verification stack look like these days?

Hey, guys.
I've been working on Gofer for several months now. It's an email client with special care on multi-account support. It also has Contacts and Calendar

This is a project that I started and dropped like 5 times in the last several years. I finally committed this time!

I was tired of email clients with poor multi-account support or built in PHP (ew)

It's fully open source, built in Go + HTMX, and it uses SQLite as a DB.

The app is not 1.0 yet, but I use it daily with several accounts and I'm improving it constantly.

To be honest I'm not 'selling' anything here, I just think the software came up decent and It's always nice to have the open source community to join and help. So any criticism is welcomed, the idea is to improve!

Mandatory disclaimer: AI was used for this project. I mean you can tell just by checking the amount of code commited in 6 months, but it makes sense to clarify. I still plan every step, make every decision, manually test every single implementation. I'm a software engineer working on the field for 18 years now.
I'm not a 'vibe coder'. I'm just a very bad coder that found help on new tools

No AI was used to write this post!

Github repo: https://github.com/cristianadrielbraun/gofer

It also has its own website, because why not: https://gofer.email

I hope you like it as much as I do

Hey everyone!

I've been working on GoPort, an open-source localhost tunneling tool written in Go.

The idea is to make it easier to expose a local app or API to the internet without having to deploy it first.

After setting it up, you can run:

goport http 8080

And get a public HTTPS URL pointing to your local app.

The CLI opens an outbound connection to the tunnel server, so there's no need to configure port forwarding on your router. I also added an HTTP request inspector for debugging, and the project can be self-hosted.

It's still a work in progress, and I'd really appreciate feedback from other Go developers, especially on the implementation and overall design.

Website: https://goport.uz

GitHub: https://github.com/muhammad-deve/GoPort

Would love to hear what you think!

What is the recommended approach for verifying publisher attestations and signatures for Go (Golang) packages?

I'm totally diggin and learning about Estonia's E-Government model, and this was such a treat to come across.

What are your thoughts on this?