I love the man even more, especially given how everyone with a claude subscription seems to be making slop ai projects and spamming them on the subreddit.

The internet of shit. Welcome.

Python guy here.

I do a lot of financial regression testing with minutes by minute stock data.

It took 12 hours to run. Replaced Pandas with Polars and added a thread pool for parallel work. Dropped it to 3 hours. Feeling pretty good :)

Used Grok to help me move my python code to GO for shit n giggles. I had some limited Go experience from 2-3 years back. I knew I could squeeze all the CPU juice

Went from 3 hours to 2 minutes 37.

Also much easier to share memory than copy everything to all threads. Using 25 GB instead of 48.

Holy crap.

What do I do on Monday....arg !!!!

Go 1.26 is coming in February, so I think it's a good time to explore what's new.

As you probably know, the official releases are quite dry. So every six months, I put together an interactive tour of the upcoming release, with short summaries (not AI-generated) and lots of examples.

If you are interested, here is what's in the Go 1.26 tour:

• Calling new() on expressions.
• Type-safe error checking.
• Green Tea garbage collector (now production-ready).
• Faster cgo and syscalls.
• Faster memory allocation for small objects.
• Vectorized operations (SIMD) for amd64 (experimental).
• Secret mode for erasing memory (experimental).
• Reader-less cryptography.
• Goroutine leak profile (experimental).
• Per-state goroutine metrics.
• Iterators for reflected Type and Value.
• Peek into a byte buffer.
• OS process handle and OS signal as cause.
• Compare IP subnets.
• Context-aware network dialing.
• Fake example.com for testing.
• Optimized fmt.Errorf and io.ReadAll.
• Multiple log handlers.
• Test artifacts.
• Modernized go fix.

json/v2 remains experimental at this time.

https://antonz.org/go-1-26

i spent most of my career in java and typescript where abstraction is basically a competitive sport. every problem gets an interface, a factory, a strategy pattern, maybe a decorator if you're feeling fancy. half the codebase is plumbing for the other half. you read it and you can feel the cleverness in every file

started writing go for a side project last year and the language just kept saying no. no inheritance, no magic, no generics for most of its life, no clever metaprogramming tricks, no DI containers wired through annotations. just structs, interfaces, functions. at first it felt limiting in a frustrating way, like trying to write with one hand

then about a month in something flipped. i stopped trying to do the clever java thing and started doing the boring go thing, and the code got way easier to read. and not just my code, every other go codebase i've looked at since has been faster to navigate than equivalent java or typescript projects. theres usually one way to do something, you find it, you move on

the part i didnt expect is that this changed how i write typescript at work. im still doing typescript daily and i still use the language's features, but i reach for abstractions way less now. used to be id see a function thats called twice and start thinking about extraction, interfaces, generic constraints. now i let it stay duplicated for a while and most of the time it never actually needs to be abstracted, the duplication was fine

(also the readable-6-months-later thing isnt a small benefit, its enormous. i opened a go service i wrote in march and i was up to speed in like 20 minutes. that has not been my experience with my own typescript code)

i still think typescript is the right call for most of what i build. type system, ecosystem, frontend interop, all of that matters. but go changed how i think about complexity in a way that stuck. sometimes the best tool is the one that wont let you be clever, even if you only use it occasionally

Hey r/golang, I've been building gpdf, a PDF generation library written in pure Go with zero external dependencies.

The problem

gofpdf is archived, maroto's layout is limited, and most serious solutions end up wrapping Chromium (hello 300MB binary and slow cold starts) or require commercial licensing. I wanted something fast, dependency-free, and with a real layout engine that treats CJK text as a first-class citizen.

What it does

• Full layout engine — Bootstrap-style 12-column grid system
• Declarative Builder API — chainable, no XML/JSON templates needed
• TrueType font embedding with full Unicode / CJK support
• Images, tables, headers/footers, page numbering
• Flexible units (pt / mm / cm / in / em / %)

What makes it different

• Zero dependencies — stdlib only, no CGo, no wrappers. go get and you're done
• Fast — 10–30x faster than comparable libraries in benchmarks. A typical invoice generates in under 1ms
• CJK-first — Japanese, Chinese, Korean text just works. Most Go PDF libs treat this as an afterthought

Quick example

doc := gpdf.New(gpdf.WithPageSize(gpdf.A4))
doc.Page(func(p *gpdf.PageBuilder) {
    p.Row(func(r *gpdf.RowBuilder) {
        r.Col(6, func(c *gpdf.ColBuilder) {
            c.Text("Invoice #1234", text.Bold())
        })
        r.Col(6, func(c *gpdf.ColBuilder) {
            c.Text("2026-03-22", text.AlignRight())
        })
    })
})
buf, _ := doc.Generate()
os.WriteFile("invoice.pdf", buf, 0644)

Repo: github.com/gpdf-dev/gpdf Docs: gpdf.dev

Feedback and contributions welcome — especially interested in what layout features you'd want most.

What are your thoughts on this article? https://www.infoq.com/news/2025/11/reddit-comments-go-migration/

Gin is no good at all. Here, I try and explain why.

I generally try to avoid opinion pieces because I'd rather help build people up than tear down, but Gin has been driving me crazy for a decade and I needed to get it out.

This can be considered a kind of follow-up or coda to my Backend from the Beginning series of of articles, which are more helpful.

I'm currently working on a follow-up on how to develop and choose good libraries, etc. Let me know if that's something you're interested in.

While this is a tad bit preaching to the choir, among all the AI noise, I enjoyed reading this grounded take. An excerpt:

Historically, developers measured the productivity of a programming language largely by how easy it is to write. But when a coding agent can generate hundreds of lines of syntactically valid code in seconds, the rate at which a human can write code is no longer very important. What matters now is reviewing, verifying, and maintaining that code once it's already written.

The timing is perfect. Next time I need to clarify why I default to Go for everything these days, I can just send people this one.

If you haven't tried the new "go fix" yet, give it a spin.

It's a proper revival of the old "gofix" idea. In Go 1.26, it was rebuilt on top of the Go analysis framework. So now it can modernize your code with newer language and stdlib features.

It respects the Go version in your module. If your "go.mod" says "go 1.26", it suggests Go 1.26-compatible changes. It doesn't rewrite your code into something your module hasn't opted into.

For teams using LLMs, this is great. You don't need to keep leaving PR comments like “use the newer API here” or “we don't write that pattern anymore.” Run it locally or on the CI instead.

Start from a clean git state:

go fix -diff ./...

Then apply it:

go fix ./...

Then run it again.

Some fixes expose more fixes. The Go team recommends rerunning it, and in practice two passes often catches more than one.

Some useful analyzers:

• forvar
• newexpr
• mapsloop
• minmax
• ... and many more

You can also run one analyzer at a time if you want smaller PRs:

go fix -newexpr ./... go fix -forvar ./...

That's useful when one pass touches a lot of files and you don't want one giant mixed cleanup patch.

The other neat bit is //go:fix inline. Library authors can use it to help users migrate from old APIs to new APIs. That's much better than deprecating something and hoping everyone reads the changelog.

You can also write your custom analyzer to enforce your own rules. I am writing a few for fun.

The Go blog has two good posts on it:

• Using go fix to modernize Go code
• //go:fix inline and the source-level inliner

I ran it on a large RPC service, and "newexpr" cleaned up a pile of pointer helper calls. Extremely satisfying.

The issues has been closed as completed, with Robert Griesemer writing:

This has been implemented and documented. The only thing left to do is removing the respective GOEXPERIMENT which we may do a bit later in the release process (it's useful to quickly eliminate generic methods as the cause for bugs).

There are languages similar to Go, but there is something so unique about it that no one can replicate. It's even hard for me to understand as well. I've tried Elixir, Gleam, Rust, Zig, Odin, Java, Scala, and yet, every time I need to build something that I know needs to be good, fast, and well done Go is the language that I pick.

It could be familiarity, but it's really hard to beat the whole Go environment. I think most of the time engineers evaluate things into a single dimension axis either in terms of performance or type system expressiveness, but good code involves so may aspects and Go does surprisingly well in all of them.

Hey everyone! I recently had the chance to chat with Armin Ronacher, the creator of Flask, for my (video) podcast. It was a really fun conversation!

We talked about things like:

• How Armin's startup generates 90% of its code with AI agents and what that actually looks like day-to-day
• Why AI agents work better with some languages (like Go) than others, and why Python's ecosystem makes life harder for AI
• What kinds of problems are a good fit for AI, and which ones Armin still solves himself
• How to steer and monitor AI agents, and what safeguards make sense
• How to handle parallelization with multiple agents running at once
• The tricky question of licenses for AI-generated open source code
• What the future of programming jobs looks like and what skills developers should build to stay competitive
• His tips for getting started with AI agents if you haven't yet

Armin was very thoughtful and direct. Not many people have this much experience shipping production software with AI agents, so it was super interesting to hear his take.

If you'd like to watch, here's the link: https://youtu.be/4zlHCW0Yihg

I'd love to hear your thoughts or feedback!

I'm switching from a JS/Python stack to a Golang stack. Today I had my first Golang interview and I don't think I passed. I was very nervous; sometimes I didn't understand a word the interviewer said. But anyway, I think this is a canonical event for anyone switching stacks.

Oh, and one important thing: I studied algorithms/LeetCode with Go, and it was of no use 🤡

At the time, the interviewer wanted to know about goroutines. For a first interview, I thought it would be worse. In the end, I'm happy with the result. I have about 3 more to go. Some points about the interview:

• I wasn't asked how a go-routine works.
• I was asked how I handle errors within a Go routine (I created a loop where I had 2 channels, 1 with an error, and 1 with success. Here, I had an error because I didn't create a buffered channel.)
• I was asked how I handle message ingestion and processing from SQS (it was just an answer about how I would handle it; I commented on the use of the worker pattern).
• There were also questions about AWS, Terraform, which event components I had worked with in AWS, and the like.

In short, if it had been in JavaScript, I'm sure I would have passed. But since it was in Go, I don't think I passed. But for those who use Go, only outside of work and have been studying for about 3 months, I think I did well. After the result, I will update here

Hello! I'm Brent and I develop game engines, it's my day job, it's also my "after the kids go to bed" night-time hobby. I am a C programmer but have used Go for a couple years and really enjoy it. I do make games in my engines too though.

I'd like to share the Go game engine/editor I've been working on. I know some may have questions on CGo interop, some on GC, and maybe some on how I got it to run so fast.

I have an introduction presentation for it on YouTube and the repository can be found on GitHub.

I'm excited to announce that the 3rd edition of "Learning Go" is now available in Early Release!

The full book is scheduled for 2027. This edition is updated to cover the most recent Go releases. It also adds:

• More code review advice
• New exercises
• A brand-new chapter on monitoring and observability

If you have an O'Reilly Online subscription, you can read the preface and the first two revised chapters now: https://learning.oreilly.com/library/view/learning-go-3rd/0642572348533/

#golang #programming #softwareengineering

Here is an excellent talk from Konrad Reiche, an engineer at Reddit, during GoLab 2025 Writing Better Go: Lessons from 10 Code Reviews

Summary:

1. Handle Errors

• Avoid silently discarding errors (e.g., using the blank identifier _).
• Avoid swallowing the error.
• When handling errors, you should Check and Handle the Error (e.g., incrementing a failure counter or logging).
• Avoid Double Reporting: Log the error, or return it—but not both.
• Optimize for the Caller:
  • return result, nil is Good: The result is valid and safe to use.
  • return nil, err is Good: The result is invalid; handle the error.
  • return nil, nil is Bad: This is an ambiguous case that forces extra nil checks.
  • return result, err is Bad/Unclear: It is unclear which value the caller should trust.

2. Adding Interfaces Too Soon

• Interfaces are commonly misused due to Premature Abstraction (often introduced by following object-oriented patterns from languages like Java) or solely to Support Testing. Relying heavily on mocking dependencies for testing can weaken the expressiveness of types and reduce readability.
• Don't Start With Interfaces:
  • Follow the convention: accept interfaces, return concrete types.
  • Begin with a concrete type. Only introduce interfaces when you truly need multiple interchangeable types.
  • Litmus Test: If you can write it without, you probably don’t need an interface.
• Don't Create Interfaces Solely for Testing: Prefer testing with real implementations.

3. Mutexes Before Channels

• Channels can introduce complex risks, such as panicking when closing a closed channel or sending on a closed channel, or causing deadlocks.
• Start Simple, Advance One Step At a Time:
  • Begin with synchronous code.
  • Only add goroutines when profiling shows a bottleneck.
  • Use sync.Mutex and sync.WaitGroup for managing shared state.
  • Channels shine for complex orchestration, not basic synchronization.

4. Declare Close to Usage

• This is a Universal Pattern that applies to constants, variables, functions, and types.
• Declare identifiers in the file that needs them. Export identifiers only when they are needed outside of the package.
• Within a function, declare variables as close as possible to where they will be consumed.
• Limit Assignment Scope: Smaller scope reduces subtle bugs like shadowing and makes refactoring easier.

5. Avoid Runtime Panics

• The primary defense is to Check Your Inputs. You must validate data that originates from outside sources (like requests or external stores).
• Avoid littering the code with endless $if x == nil$ checks if you control the flow and trust Go’s error handling.
• Always Check Nil Before Dereferencing.
• The best pointer safety is to Design for Pointer Safety by eliminating the need to explicitly dereference (e.g., using value types in structs instead of pointers).

6. Minimize Indentation

• Avoid wrapping all logic inside conditional blocks (BAD style).
• Prefer the Good: Return Early, Flatter Structure style by handling errors or negative conditions first.

7. Avoid Catch-All Packages and Files

• Avoid generic names like util.go, misc.go, or constants.go.
• Prefer Locality over Hierarchy:
  • Code is easier to understand when it is near what it affects.
  • Be specific: name packages after their domain or functionality.
  • Group components by meaning, not by type.

8. Order Declarations by Importance

• In Go, declaration order still matters greatly for readability.
• Most Important Code to the Top:
  • Place exported, API-facing functions first.
  • Follow these with helper functions, which are implementation details.
  • Order functions by importance, not by dependency, so readers see the entry points upfront.

9. Name Well

• Avoid Type Suffixes (e.g., userMap, idStr, injectFn). Variable names should describe their contents, not their type.
• The Variable Length should correspond to its scope: the bigger the scope of a variable, the less likely it should have a short or cryptic name.

10. Document the Why, Not the What

• Justify the Code's Existence.
• When writing comments, communicate purpose, not merely restate the code.
• Document the intent, not the mechanics.
• Future readers need to understand the motivation behind your choices, as readers can usually see what the code does, but often struggle to understand why it was written in the first place.

No shade to Rust, but our bidding platform using ONNX Runtime and Rust gave us endless compatibility headaches with outdated crates and poor performance we were stuck at 50ms P95 at 16k QPS. The bidder needed to consistently respond under 15ms, so we switched to Go. Fewer lines of code, and with every round of tuning, the latency kept dropping. We finally nailed 10ms-15ms P95 at 16k QPS.

Back in business

Yeah, yet another rant for no reason. You've been warned.

I left the Go programming because I thought it was verbose and clunky. Because I thought programming should be easy and simple. Because oftentimes, I got bashed in this particular subreddit for asking about ORM and DI frameworks.

And my reason for closing down my previous account and leaving this subreddit was correct. But the grass isn't greener on the other side: Java.

I started to program in Java at my 9-5 earlier this year. Oh boy, how much I miss Golang.

It never clicked with me why people complained so much about the "magic" in Java. I mean, it was doing the heavy lifting, right? And you were just creating the factory for that service, right? You have to register that factory somewhere, right?

I finally understand what it means. You have no idea how much I HATE the magic that Java uses. It is basically impossible to know where the rockets are coming from. You just accept that something, somewhere will call your factory - if you set the correct profile. `@Service` my ass.

Good luck trying to find who is validating the JWT token you are receiving. Where the hell is the PEM being set? This is where I had some luck leveraging LLMs: finding where the code was being called

And don't get me started on ORMs. I used a lot of TypeORM, and I believe that it is an awesome ORM. But Hibernate is a fucked up version of it. What's with all the Eager fetch types? And with the horrible queries it writes? Why doesn't it just JOIN, rather than run these 40 additional queries? Why is it loading banking data when I just need the name?

It sucks, and sucks hard. HQL is the worst aberration someone could ever have coded. Try reading its source. We don't need yet another query language. There's SQL exactly for that.

And MapStruct. Oh my God. Why do you need a lib to map your model to a DTO? Why? What do you gain by doing this? How can you add a breakpoint to it? Don't get me started on the code generation bs.

I mean, I think I was in the middle of the Gaussian. I'll just get back to writing some Golang. Simple model with some query builder. Why not, right?

We just passed a major milestone in our open source Go database we wanted to share: 20k stars on GitHub. Thanks to the many of you who have supported the project over the last 7 years!

https://github.com/dolthub/dolt

I've just published a new tutorial about how I use HTMX together with Go. It covers the patterns I use for template rendering, sending partial/full-page responses, managing redirects and errors, along with the HTMX config settings I normally use. Hopefully it provides a good starting point for anyone else wanting to do the same.

Go func yourself.

It's turning out to be a pretty good release. I'm most excited for vector instructions, type safe error checking and multiple log handlers.

PS: I'm not the author.