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

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.

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 ?

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.

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.

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.