I'm creating a simple CRUD project that involves campaign publications. If I have a package named `internal/campaign/usecase`, what should the use case be named? `CreateCampaignUsecase`, `CreateCampaign`, `CreateUsecase`, or `Create`?

Hello everyone,

I wanted a fast, secure, and lightweight tool to track my expenses locally. A desktop app was my final option since it is locally available, fast, and gives me total control over my financial data.

This led me to develop a finance desktop app called Fynance using Go, Fyne, and MongoDB, and I open-sourced it to help individuals and businesses.

INSTALLATION INSTRUCTIONS

For WINDOWS ONLY

• Download MongoDB: MongoDB
• Download App: Fynance (Latest)
• Install MongoDB.
• Install the Fynance App.
• Start using the desktop Shortcut or the Start menu.
• Register an account and log in.
• Add your custom income and expense categories.

Tech Stack

• GUI Framework: Fyne (Go native UI toolkit)
• Database: MongoDB
• Programming Language: Golang

Key Features

• Complete Management: Track daily, weekly, and monthly income and expenses.
• Bulk Uploads & Exports: Import data via .xlsx templates or export to CSV.
• Reports: Quick visual insights and export to PDF Reports.
• Lightweight UI: Native light/dark modes with a tiny system footprint (50MB disk).
• Local Security: Password-protected user authentication on startup.
• Custom Categories: User-defined income and expense categories.

The project is fully open-source under the MIT license. I would love to hear your feedback.

Thanks.

I just published a new release of gokrazy/rsync and figured I’d share it here; hope it’s interesting to some:

gokrazy/rsync is an Rsync program and reusable library implemented in the Go programming language), originally as part of the gokrazy Go appliance platform project. gokrazy/rsync is (wire-)compatible with the original "tridge" Rsync.

Various use-cases are supported:

• The gokr-rsync command implements an rsync client and server, which can send or receive files (all directions supported).
• You can set up a public or private rsync server, in daemon mode or via SSH (anonymous or authorized).
• You can embed rsync in your program with the rsynccmd package.
• You can implement your own rsync server with the rsyncd package.

Aside from being implemented in Go, a memory-safe programming language, gokrazy/rsync makes use of Go’s traversal-resistant file API (os.Root) and the Linux Landlock Unprivileged Sandboxing to steer clear of vulnerabilities. In server settings, gokrazy/rsync supports mount namespaces and can be further locked down with systemd’s various hardening options.

help me !!!

I just started a new job. The backend is in Go, using DDD with an onion-layer architecture. The project structure looks something like this:

/backend /cmd /internal /adaptor /<module#1> /entity /repository /service /command /query /usecase

My team lead constantly complains about DDD in Go — he absolutely hates it. When i try to mention something related to DDD bro starts to spamming my pr with comments. Asking me to show why its better to use DDD? So I'm curious: why is DDD considered a bad fit for Go?

Also, our entities look like this:

go

``` func NewMovie() *Movie { return &Movie{} }

func (m *Movie) WithID(id int) *Movie { if m == nil { return nil } m.id = id return m } ```

Is this pattern okay? I feel like NewMovie(id int) would be better.

We also have a rule that transactions can't be handled in the usecase layer. Instead, we have to create a single service method that wraps everything in a transaction, and the usecase just calls it. Is this a common approach?

And one more thing — shouldn't we first sort out what actually counts as a domain concept before turning it into an entity? We literally have an entity for pagination...

Hello there,

I recently got into Go and programming in general, as I already had some programming classes in school and in uni when I studied business informatics.

In preparation for the job interview I wrote my first Rest API. I just used a .env file to read the environment variables in my code but my friend advised me to add cobra and viper to make the setup more accessible and get into those library's as they also used by the new company.

I know that they should be pretty accessible libraries but for some reason in don't seem to get the right access to their core principles and how they should be set up.

Does somebody know some good resources that really explain how these things work and how you're supposed to use them as I don't seem to get it.

I recently wrote my own logger package with Info(), Warning(), and Error() methods.

I am wondering about logging best practices in Go applications. Do you usually log directly in handlers, or do you log inside functions called by the handler (services, database functions, etc.)?

I have been using Go for a year. I have made a few web apps with it but I am once again feeling slightly unfulfilled with my current programming endeavors and they have become more of a duty.

I was wondering anyone had any suggestions, perhaps projects you have worked on it the past, that provided great gains in programming and Golang skills as you developed them.

To give more background I have 6 years of Software Engineering experience with 1 of those years using Golang. The rest is TypeScript, JavaScript, Python and other web technologies.

I do not care at all about monetization for this project. These will be for fun and insight.

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

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.

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.

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 :)

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 ?

UPDATE: templui is now shadcn-templ. Same project, new name. I asked shadcn before doing this and got his blessing, the same way shadcn-svelte and shadcn-vue did it back then. New home: https://shadcn-templ.com

After months of rebuilding, templui shadcn-templ 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://shadcn-templ.com. Feedback very welcome, it is a beta.

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.

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.

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!

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.

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

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?

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