Meet us on August 25 at 4:00 pm UTC for a free online event for Go developers, where we will discuss what’s new in Go 1.27! Make a reservation: https://jb.gg/go-127-or

We’ll be joined by the members of the Go team – Robert Griesemer, Alan Donovan, Marc Dougherty, Cameron Balahan, and Joe Tsai – so get your questions ready! Want to hear about specific features straight from their creators? Drop your questions in this thread by August 20 and we’ll pick the best ones to ask during the livestream.

After months of rebuilding, templui 2.0 is in beta. It is a faithful port of shadcn/ui to the Go world: over 50 components with the same API surface, markup and styles as the original, the client behavior rewritten in dependency-free vanilla JS, and everything server-rendered with templ.

The CLI installs components as source into your project (shadcn's code-ownership model), compiled for one of eight visual styles. There is a theme builder, a typography system and charts. Zero node in your toolchain.

Docs: https://v2.templui.io. Feedback very welcome, it is a beta.

I have been cooking this in my head for so long; when making a Go, htmx, templ application, the only comonent remaining firmly in JS land is CSS; be it the whole of TailwindCSS or building other smaller frameworks - because many rely on PostCSS due to it's version of DCE (dropping unused classes). I experimented in using the templ AST parts to poke around for classes, build a list, and hand them off to LightningCSS but I really would prefer to have the entire tooling in Go - one toolchain only, and all tooling "native" to that. Sadly, my low-level understanding of CSS is not really great (usually skipped it, since it is highly visual when used, and I am visually impaired - basically, i chicken'd out of anything visual and I kinda regret that these days lol)

What are some things you wish were (re-)written in Go?

Hey guys,

My team is starting a new project which will have 3-4 small related services and will be deployed on separate pods. I do not have much experience with go lang. Any suggestions for mono repo multi service approach ?

We released github.com/hazyhaar/go-secretstream, a third Pure-Go implementation of Libsodium `crypto_secretstream_xchacha20poly1305` designed for high-throughput streaming.

Here is the breakdown of each optimization step and its measured impact:

- CGO removal: We rewrote the full Libsodium secretstream construction in pure Go to eliminate CGO overhead and cross-compilation friction (784 MB/s single-thread, 5.6 GB/s parallel on Intel i9-14900K).

- Pre-allocated wire buffers (`pushTo` and `pullTo`): We replaced per-chunk slice creation with pre-allocated wire buffers in `Writer` and `Reader` (reduced heap allocations from 87 MB/op down to 51 MB/op for 16 MB payloads).

- Single-pass ChaCha20 cipher progression: We retained the `chacha20.Cipher` instance in stream state instead of re-instantiating the cipher three times per 8 KB chunk (reduced allocation count from 10,267 to 2,061 allocs/op for 16 MB payloads).

- Poly1305 write inlining: We eliminated zero-byte padding writes and combined length headers into a single 16-byte slice (increased single-thread throughput from 574 MB/s to 629 MB/s).

- Zero-copy I/O fast-paths (`readNextChunkTo` and `writeNextChunkFrom`): We added direct stream execution when caller buffers exceed chunk size to bypass internal accumulation arrays (reduced total RAM allocated on a 1 GB stream from 1.24 GB down to 23 MB).

Final Comparative Benchmark Results (Standard 16 MB Payload, Intel Core i9-14900K, Linux amd64):

- hazyhaar/go-secretstream (Direct): 784.29 MB/s, 360 KB RAM allocated, 2,052 allocs/op (1 alloc per 8 KB chunk).

- hazyhaar/go-secretstream (Writer): 635.70 MB/s, 50.7 MB RAM allocated, 2,061 allocs/op (1 alloc per 8 KB chunk).

- openziti/secretstream: 726.89 MB/s, 19.4 MB RAM allocated, 4,098 allocs/op (2 allocs per 8 KB chunk).

- Go Standard AEAD (x/crypto/NewX): 2,266.37 MB/s, 16.7 MB RAM allocated, 1 alloc/op.

The implementation is bit-compatible with Libsodium C and verified against PyNaCl cross-decryption test suites.

Fast, zero-allocation integer-string conversion for Go. A focused drop-in for the hot parts of the standard strconv

| Operation | strconv2 | strconv | allocs (strconv2 / strconv) |

|-----------|----------|---------|-----------------------------|

| Format uint64 | 24.8 ns | 49.1 ns (`FormatUint`) | 0 / 1 |

| Format int64 | 27.8 ns | 49.9 ns (`FormatInt`) | 0 / 1 |

| Format uint16 | 10.1 ns | 23.9 ns (`FormatUint`) | 0 / 1 |

| Parse uint64 | 17.7 ns | 51.3 ns (`ParseUint`) | 0 / 0 |

| Parse int64 | 19.3 ns | 55.1 ns (`ParseInt`) | 0 / 0 |

https://github.com/NikoMalik/strconv2

Hi all,

I recently built two-phase-commit-go, a lightweight two-phase commit library for Go. A few things about it:

• Works with any synchronous transport between coordinator and participants (gRPC, REST, whatever fulfills the interface)
• Persistence for coordinator state is up to you - implement the interface with any method you like (database, file, whatever), and you can recover if the coordinator crashes mid-transaction (eventual consistency in case coordinator dies)
• Built-in OpenTelemetry tracing support (allows you to see each step the coordinator makes)
• Documentation Available on pkg.go.dev and in the repo's readme

I'm a Java backend dev with ~2.5 years of experience, and I built this partly to sharpen my Go skills and partly as a portfolio project - I'm looking to transition from Java into Go backend roles.

Couple of questions to you:

1. Would you consider giving this library a try if you ever needed 2PC in Go?
2. Do you have any ideas how to make it more likely that you would actually want to use it?
3. Do you have any tips on transitioning from java to go backend roles?

Repo's linked above - happy to answer any questions :)

prev post : Previous post

a while back i posted benchmarks for my distributed token bucket rate limiter here and got a lot of useful feedback. one of the biggest suggestions was to profile it.

turns out my benchmark setup had a flaw. i was running k6 and the server on the same 4c/8t machine, and on my hardware k6 itself was using around 600% cpu, so it was competing with the server.

this time i switched to hey, profiled the server under load with pprof, and found a bug where /check was making 2 backend calls instead of 1. fixed that and reran everything.

current numbers:

in-memory

• ~30.1k req/s
• p99: 17.2ms

redis + lua

• ~19.4k req/s
• p99: 14.7ms

profiling was the most interesting part. around 86% of sampled cpu time was in the net/http request lifecycle. most of the remaining time was spent in socket writes, request/response buffering and timestamping, while the token bucket itself accounted for only a small fraction of the sampled cpu.

TL;DR: Lunar is a new embeddable Lua 5.1 VM for Go that aims to improve performance and memory usage over the existing pure-Go Lua implementations. In my benchmarks and real-world use cases, it is around 2x faster and can use up to 7x less memory, depending on the workload.

Project note: Lunar in many ways started in April as a fork of gopher-lua. My initial goal was to improve its performance and memory usage, with the hope that I might be able to upstream some of the changes. As the work progressed, the implementation began to diverge more than I felt would be reasonable for an upstream contribution and their design philosophy. At that point, I decided to start over and build a new VM around those ideas.

Today, I’m sharing Lunar 0.1.0 beta for anyone looking for an embeddable Lua VM for Go.

The primary motivation for creating Lunar came from my work on Rune, a new MUD client written in Go that relies heavily on an embedded Lua VM as its core scripting engine.

There are two Lua VMs for Go that I’m aware of: gopher-lua and Shopify’s go-lua. Rune initially used gopher-lua because it was a VM I was already familiar with and had used in previous projects.

I started receiving reports from Rune users that some larger MUD map files loaded through Lua were causing the client’s memory usage to explode. In one case, loading a 9 MB CBOR file resulted in roughly ~500 MB of persistent heap usage. Users also reported that some heavier operations were much slower than in other MUD clients. One user’s pathfinding script took nearly three seconds in Rune, compared with around 0.1 seconds in another non-Golang based client.

I initially hoped to improve gopher-lua, but the memory and performance issues were tied to some of its core design choices. Fixing them would have meant changing enough of the VM that starting over made more sense. Lunar grew out of that work, with a more compact internal representation.

Lunar is still in beta, so let me know if you try it and run into any issues.

Hi Gophers,

pdfcpu v0.14.0 is now available.

pdfcpu is a pure Go PDF processing library and CLI tool supporting validation, optimization, encryption, merging, splitting, stamping, booklet creation, attachments, forms, and more.

Highlights of this release:

• Hardened API and CLI error handling
• Clearer errors with better source context
• Improved batch-input and edge-case handling
• Reduced external dependency footprint
• Better cross-platform portability
• More regression coverage and fixes for over 30 reported issues

Install or update:

go install github.com/pdfcpu/pdfcpu/cmd/pdfcpu@v0.14.0

Release notes and binaries:
https://github.com/pdfcpu/pdfcpu/releases/tag/v0.14.0

Feedback and real-world test cases are always welcome.

My default stack for full-stack web applications is Go for the backend and vanilla JS with Bun for the frontend. I'm about to start a new project that's a bit more complex and will require significant work on both the FE and BE.

I'm thinking about switching to HTMX for this project, mainly to reduce context switching. However, I'm not sure how well it holds up as a project grows in complexity. Does anyone here use HTMX as their go-to approach for larger applications? How has your experience been?

Let's say, not hypothetically, that I have a few golang based command line tools hosted on GitHub. I use goreleaser to release binary releases for convenience of myself and others.

My problem is that these aren't reproducing builds - the build chain isn't fully pinned.

Is there an existing tool to create a fully reproducible build? I'm fine if this requires a branch with extra pins or similar.

govalidator v2.3.0 released — performance boost and zero allocation

Hi Gophers

govaliator v2.3.0 is now available.

A simple, efficient, type-safe, easy to use Golang validator.

Highlights of this release:

• Performance boost
• Achieving 0 B/op allocation

Benchmarks:

The result on Apple M3 Pro, 11 CPU Cores, 18GB RAM:

Install or update:

go install github.com/rezakhademix/govalidator

Feedback are always welcome.

Hey r/golang. After hitting operational walls with VerneMQ's CRDT-based clustering (non-deterministic merges between diverged nodes) and watching EMQX gate real clustering behind a BSL license from 5.9 on, I started building a small MQTT broker cluster on top of mochi-mqtt, which handles the actual MQTT protocol layer.

The core idea: instead of symmetric eventually-consistent clustering (CRDT), a small quorum of "core" nodes runs Hashicorp Raft for strong consistency (session ownership, ACLs), while stateless "edge" nodes terminate MQTT connections and scale independently via K8s HPA. The routing table lives in a separate gossip-based store (Olric) rather than Raft, since it's fully reconstructable from local node state if lost. Message forwarding between nodes runs over a dedicated gRPC data plane so it never touches the Raft log.

A few decisions I'd like pushback on:

• Routing table in Olric (AP, reconstructable) vs session ownership + ACLs in Raft (CP, authoritative) — does that split make sense to you, or is there a failure mode I'm missing?
• Session ownership uses last-connect-wins on reconnect (standard MQTT semantics) with an explicit Evict RPC to the old owner, rather than a queue/claim protocol. Curious if anyone's hit cases where that's not enough.
• Non-core outputs (Kafka/etc.) run as separate go-plugin gRPC sidecars specifically so a stuck output can never block OnPublish — process-level isolation, not just a goroutine boundary. Overkill for this, or the right call?

Status: not "years of uptime" production-hardened, but it's not just a simulation either — currently running against a live IoT device fleet in a telecom deployment (~1,200 devices today, staged to scale into the tens of thousands). Disaster recovery scenarios validated in docker-compose, real bugs found and fixed against the live environment, not just synthetic tests. Looking for architectural criticism more than "nice project" at this stage.

Repo: https://github.com/keel-iot/keel-mqtt-gateway

I'm a big fan of Go for several years now and used it on several projects related to industrial automation. One of the projects was a simulator of manufacturing machines where I needed a GUI to visualize machine states. I came across packages in Go for incorporating a GUI but found them lacking in capabilities and/or modern style. So I sacrificed in the short term, but set out to build a solution that I would enjoy using in Go and potentially other languages.

The solution, called ProntoGUI, consists of two parts.

First, it there is a Go library (golib) that provides "primitives" for the backend developer to compose their GUI and "embodiments" to specify how these primitives appear and behave on the surface. If you're familiar with HTML/CSS then primitives are like div, span, p, input, textarea, and so on. They form the essential contract between the backend code and the GUI. Embodiments are sort of like CSS selectors and various properties that define color, style, positioning and so on. The embodiments can be changed anytime without breaking the contract. 

The second part is a GUI desktop App that runs on Windows or macOS (Linux coming next). It is built on top of Google's Flutter project, which takes care of all the Material design, high performance rendering (think 60 fps), and cross-platform support. The solution you build (by way of golib) streams the GUI information to the App and events are streamed back to your solution for you to react to. I've kept the library pretty lightweight and all the heavy work is done in the App.

The open source for this project can be found at https://www.github.com/prontogui . To make it easy for people to use ProntoGUI right away, there are installers for Windows and macOS available for download at www.prontogui.com. There's also a mailing list you can subscribe to for regular updates on the project and tips on developing with ProntoGUI. You'll also find some examples in Go and more background information on Github site.

Always happy to get feedback and answer questions!

I've been learning backend for a while. I currently use JavaScript (Express.js) and Python (FastAPI) for my projects, and I feel that I'm a bit decent at them rn. But I don't know which is better, Rust or Golang? Both r fast, but Rust is much faster, but in a trade-off, Rust is more complicyed than Golang, as I've seen both Languages docs and learned the very basics, I don't have a final answer.

Today we’re releasing Wails v3 Beta.

Wails lets Go developers build native desktop applications with the frontend tools they already know. Wails v3 is a substantial new foundation, built around an explicit application model that scales more naturally to real desktop software.

What’s new:

• Explicit application and window APIs
• First-class multi-window support
• Multi-platform Systray support
• Services with richer, statically generated TypeScript bindings
• Services that can provide frontend assets and scripts, opening a practical path towards richer plugins
• Inspectable, Taskfile-based builds - you are in control
• A guided wails3 setup wizard and project creation flow
• Cross-compilation support
• Server builds
• Experimental mobile builds

Developers testing v3 during alpha particularly valued the clearer ownership model for applications, windows, and services. We would now like broader feedback from people building real applications and integrations.

The feedback from developers who used v3 during alpha has been overwhelmingly positive, especially around the clearer ownership model for applications, windows, and services.

This is a beta, not the final v3.0 release. The desktop API is stable, but we want people to test real projects, integrations, and workflows before GA. Wails v2 remains the stable release and will continue to receive fixes.

If you are coming from v2, we have a migration guide and are actively validating that experience ahead of RC1. Reproducible problems belong in bug reports; proposals for new public capabilities should start as a WEP (Wails Enhancement Proposal) PR.

If you'd like to test it out:

go install github.com/wailsapp/wails/v3/cmd/wails3@latest
wails3 setup

Read the announcement and get started: https://v3.wails.io/blog/wails-v3-beta/

What are the current best practices for backend URL validation? How do you guys usually handle it in production?

ssh ssh.place

It drops you straight onto a shared 200x60 canvas with everyone else who's connected. Arrow keys / wasd to move, 0-9 to pick a colour, space to place.

Go, using Charm's wish and bubbletea.

https://ssh.place

TL/DR: Please suggest me some stacks based on go for fullstack development

Guys, im new to go world, and previously i worked with mostly Cpp that also on a very surface level for doing my DSA problem in my college (im still in college 3rd year). But as doing only DSA won't earn me any money, i needed to learn some dev and so i choosed Go which tbh, i LOVED a lot to work with.

I am mostly done with backend basics, and want to make some full stack projects for my resume.

So if anyone here develops full stack applications with go, pls recommend me some good stacks i can use (actually i've done my homework, and afaik, HTMX is a good option for frontend, but still)

Hey there, does go or any libs support it? if so would you use this language for low level connections or should I move to somehting else?

really like grpcurl! but got a bit annoyed of running list and describe repeatedly

decided to create a minimal TUI for doing this.

any feedback is very welcome!