Gophercon Korea 2025: A Review

https://gophercon.kr/

I figured if I waited until after this year ended, I’d never write this up at all, so here’s a quick review of Gophercon Korea, which I went to last month on the 9th at Magok COEX.

Going in

Back in my SW Maestro (let’s call it SoMa) days, and during the early years of running my own startup, there were a lot of events like Naver DEVIEW (Naver’s annual dev conference), and I went to plenty of them. Once you started showing up, it was kind of like a class reunion. You’d run into everyone you knew, exchange greetings, and drift between sessions together. During SoMa I think it was JCO (a Java developer conference) where the whole team went and even gave a talk. That was already ten years ago in calendar terms. After that, while running the company, I cared more about business and operations than about hands-on engineering, and even though I kept coding, I more or less lost track of dev conferences. After COVID I forgot they even existed.

At my last company, every now and then a teammate would ask if they could go to one of these on a weekday, and I’d approve and send them. Once COVID hit, most of these talks went straight to YouTube (either live or right after), so my pattern became: skip the event, then look up a topic I cared about whenever I felt like it.

After I left the company, I started writing the occasional thread on Threads. Someone read my recent backend post and a thread of mine on running test code, then reached out by DM: “Are you going to Gophercon this week? If you are, I’d love to grab a quick coffee chat.” Truth is, I knew Gophercon existed but had no idea it was happening that very week (November 9), and the idea of attending myself hadn’t even crossed my mind, so I was caught off guard. But I also wanted to talk shop with engineers and get back to events, and give George (who got into Go because I’d put him on a Go backend) a taste of the gopher world (?). So I bought tickets right there: a sponsor ticket for me, a regular ticket for George. To the backend engineer who DM’d me I replied, “Of course I’m going. Want to meet up briefly that day?” Maybe I just didn’t want to admit on Threads, where I cosplay as a Go engineer of sorts, that I had no clue. (Of course I confessed all of this when I actually met him on the day. Told him: thanks to you, I ended up going.)

The talks

I caught almost everything except for one or two slots I skipped for coffee chats, but I’ll only write up the talks I actually understood well enough to comment on.

• Building a real-time interpreter in Go (real-time AI inference, WebRTC)
  • I forget the company name, but it was an edtech outfit, and given the domain I paid close attention. The premise was that the most important thing in education is the “classroom” as a space, and the talk focused on how to recreate that classroom experience online. They walked through how they used Go’s concurrency to build real-time behavior, then expanded that into a global classroom, eventually layering in real-time translation with LiveKit. The step-by-step way they tackled each challenge was genuinely impressive.
  • This is one I’d like to rewatch when the recording goes up on YouTube.
• Effect-ive Go: Truly Go-flavored functional programming
  • One of the biggest things I let go of when I moved to Go was functional programming. I still pull in samber/lo occasionally, but the core of FP (immutability, monads, tight abstractions) isn’t easy to bring into Go straight, and twisting the language that hard doesn’t really feel “Go-like” either. There was a stretch where I went deep into FP, but these days I think it’s better to find the middle path that fits the language and the problem. So I was curious how the Effect pattern implements “Go-style functional” in Go.
  • To boil down the Effect pattern from this talk in one line: in your domain and business logic, you only declare side effects as “effect messages,” and the actual side-effect execution (DB calls, external APIs, logging, concurrency) gets delegated to separate effect handlers. The point is to maximize purity, testability, and reusability through a Go-style Effect Handler architecture.
  • I went through the repo, typed out the code samples, and tried mapping it onto my own codebase (a fairly large backend on DDD / clean architecture). At least for the use cases I have right now, the existing layer structure already gives me domain purity and infra separation, so adding a separate effect layer would inflate conceptual and implementation complexity more than it’d give back. It’s closer to a “more cost than benefit” pattern in my situation.
  • That said, the spot this library is aiming at is real. Go often gets used in multi-module / multi-runtime setups in production (HTTP, gRPC, batch, workers, etc.), where the same domain logic has to run across different infrastructure combinations, or you need to “interpret” the same domain logic differently across handler combinations for testing, simulation, or replay (think CQRS, event sourcing, heavily functional architectures). In those contexts, modeling logging, transactions, retries, circuit breakers, and concurrency control as explicit effects, and controlling when and how they get composed at the handler level, becomes a real advantage. That’s where experimenting with something like effect_ive_go is worth the investment.
• Test Reality Not Mocks: Reliable Go Tests in the AI Era
  • This lined up exactly with my own post arguing against DB mocking. It pushed further by showing real handler-based tests, and broadened the scope to TDD and how to write better tests in Go projects in general. When I wrote that post I said I don’t do TDD, but I’m now actually doing TDD-style coding alongside Claude Code, so this talk genuinely helped me out.
• Dev in Go way (the Go-ness of Go)
  • The most quintessentially Gophercon talk of the day. Grounded in the language itself, it walked through why patterns common to Java or other OOP languages (builder pattern and friends) don’t really fit Go, and what makes good code “good code” by Go’s spirit, by Go idiomatic standards. The speaker came across as a real veteran, but the talk itself was the easiest to follow, and I think every attendee got something out of it.
  • Small Interface is something I’m already trying out in my current backend. My repository interfaces in particular have been swelling up to the point where the code is hard to follow. Splitting both the interfaces and the files apart turned out to make the code easier to read and also reduced collisions when working on it concurrently with Claude Code, more than I expected.
  • Accept interfaces, return structs is basically unavoidable once you build clean architecture in Go. And the recommendation to use the Options pattern instead of the builder pattern (the builder pattern doesn’t fit Go cleanly because of multi-return errors) looks promising for my domain structs, especially when there are lots of constructor option values, so I’m trying that out too.

Overall

About 80% of my coding over the last six months has been Go, so directly or indirectly, all of these talks were useful. The content itself was solid. I’d like to give a talk myself sometime, from the perspective of running a service in production. Funny enough, the reason I started Go five years ago was this video: Daangn’s engineering team adopts Go, on Daangn Tech. The speaker, Byun Gyu-hyun, seems to still be at Daangn, and gave talks at Gophercon last year and the year before. He didn’t speak this year, which left me a little disappointed.

Networking

The two main groups I ended up talking to: the engineer who DM’d me first (let’s call him A) and another person who’d spotted my posts on Threads (B). A is a backend engineer who came with his Canadian CEO (C). They’re building humanlog.io, an observability service. We talked Go, and also observability experience (in my case, a lot of Datadog), Clickhouse, and so on. C joked that since I knew Go, had observability experience, and had used Clickhouse, maybe I should join them. I laughed and played along. (Pretended I didn’t catch the English.) The interesting thing is, A and C also met at last year’s Gophercon, so it was clear that, unlike A, C had come with the explicit goal of scouting talent.

B came with a Go engineer (D) he works with full time. They run a business serving small business owners and the self-employed (Korea’s SMB segment), collecting a massive amount of data using Go. Because D is the Go person, Go ended up being the main language of the business, and now that they want to seriously scale up they’re trying to hire more Go engineers, and since there are barely any around, they were attending the conference partly hoping to meet people. There was something about them that reminded me of the energy I had when I was first starting my own company. A good team. I told them honestly that finding a Go engineer right away would be hard, and that they might be better off hiring a junior who can hustle and training them up. But I left wanting them to win.

What conferences are actually for = networking

If you only count the talks, honestly, conferences like this don’t pencil out on a time-spent basis. You sit through a fixed track on a fixed schedule, and even when tracks are split by backend, frontend, data, the range inside each track is too wide. When the track is bound by a single language like Golang, the gap gets even wider. This year’s lineup ranged from vibe coding to blockchain. There were topics every Go user could relate to, and topics that, at least for me right now, I couldn’t follow or didn’t care about. That said, the parts about the language itself and goroutine concurrency are the kind of thing everyone could take something home from.

But once you fold in networking, it’s a different story. I skipped about two talks (one in the middle, one near the end) and used that time to talk with people I happened to connect with at the venue, and the common thread among them was hiring. Or some version of “this is how I’m doing Go, how are you doing it?”

When you give a talk, the best you can do per unit of time is meet one speaker. But if a talk is something you can already watch online, what brings people out in person is, I think, the networking. If conferences set aside more space and time for people to find others who share their goals or want to talk about the same things, you’d come away with something more meaningful than just sitting through sessions.

I got lucky and ended up meeting good engineers by chance. If there had been more structured opportunities, I would’ve liked to know and talk with a wider mix of people. The “opportunities” we hope for tend to come out of small talk, coffee chats, the weak ties of networking. They accumulate slowly and then suddenly turn into something. That’s been one of the bigger lessons of the past few years for me.

Gophercon in particular is a relatively small group in Korea, but it occupies a unique position (backed by sizable companies like Devcat, Daangn, and Line), so if this kind of networking grew more active, the contribution to the broader Korean Go ecosystem would expand much further.

Photos

My nametag from the venue. Google, Daangn, and DEVSISTERS were among the sponsors.

An eco-bag with a gopher in hanbok holding a taegeuk fan. A uniquely Korean Gophercon touch.

The swag that came with the sponsor ticket: a hand-knit gopher doll, stickers, keychains. A pretty generous lineup.

Heading out

It was a good outing back into a dev event after a long time, and George said he picked up a lot too, so it turned into a good day. Somewhere along the way I’d grown skeptical about events like this (the worry that you’re just chasing trends, or going because everyone else is going), but listening to talks and talking with people turned out to be a worthwhile experience.

I went to show George the gopher world, and ended up bringing something home myself. Just like five years ago when Byun Gyu-hyun’s talk got me into Go, next time I’d like to be the one giving a talk at Gophercon.

I’ll leave it at that — hoping the Korean Go ecosystem keeps getting livelier.