Phuong Le

I have made thousands of static visualizations for Go, it's time to try something new: youtube.com/watch?v=fwHok9…

@ZH1YGD Thank you, man. Appreciated.

@func25 I have been reading your book "Anatomy of Go" and like you do there, you have an amazing way to present information. Kudos!

victoriametrics.com/blog/victorial… Reading how a high-performance database lays its data out on disk in an optimal columnar layout, how bloom filters are used, how sharding columns helps with concurrency, etc, through visualization, is interesting. Written entirely for beginners, no complicated data structure knowledge required.

This was such a good read. It's densely packed and I learnt many things. The architecture seemed obvious & simple after reading but I am sure it was much harder to design it this way & still keep it simple. VM is one of the few companies that has very good tech blogs.

.@VictoriaMetrics created an open source time series database that processes hundreds of millions of samples per second. At our free and virtual @P99CONF, @hagen1778 will share the technical optimizations in #Golang that they used. ow.ly/cwJx50Zl5h6 #ScyllaDB #P99CONF

Accessing a file contents via memory map in Go may result in execution stalls when ready to execute goroutines aren't executed even if there are plenty of free CPU resources. There is a solution for this problem - read the following article from @func25 . internals-for-interns.com/posts/mmap-vs-…

Curious why VictoriaLogs is so efficient at on-disk compression of your logs and querying them at a high speed, even on HDD? Then check out the following great article from @func25 - victoriametrics.com/blog/victorial…

The first guest post on Internals for Interns is live! 🎉 @func25 wrote "mmap vs pread in a real Go storage engine", a deep dive into how VictoriaLogs decides how to read bytes from files. It sounds too low-level to matter, until you do the math. I don't want to give any spoilers, so I'll just say this: it's a great story about mechanical sympathy, understanding how Linux memory management works, how the Go scheduler works, and how a seemingly simple question can sometimes have a far more nuanced answer than you'd expect. You can read it here: internals-for-interns.com/posts/mmap-vs-… #Go

New content plan for the next 3 months in my blog! Two series running in parallel: Continuing the one about the Linux kernel (VFS, I/O, Devices, Network, NUMA...) And starting one about Go AI Inference (Yzma, Kronk, and friends) Plus guest posts from @func25 , @alextrending and @mdelapenya

My VictoriaLogs instance just hit 10 million log entries over the past 7 days. How much space is that on disk? According to du inside the jail, 426 MB: [13:37 logs dvl ~] % sudo du -ch -d 0 /var/db/victoria-logs 426M/var/db/victoria-logs 426Mtotal

I'm starting something new in my blog: one guest every month, walking through the internals of Open Source projects from their own point of view. They are going to take the first post of every month (The first Monday of the month). I'm extremely happy to have already 3 outstanding engineers in the queue. I would recommend you to go and check what they are doing (probably follow them). First up for July is @func25 from VictoriaMetrics. If you've ever fallen down a rabbit hole reading how the sync package works there's a good chance you were reading Phuong. His series on the sync package internals are very good. He's also the author of The Anatomy of Go, a deep dive into how the language actually works under the hood, from data structures and assembly to memory, the GC, and concurrency. Exactly the kind of guest this series is about. And the lineup keeps going: 🔹 @alextrending, will be the August post, he is Principal Engineer at Memed, author of System Programming Essentials with Go, and a relentless community builder. Lately he's been on stages everywhere with talks like "Green Tea GC: The Insight Behind Go's New Garbage Collector," "Tug-of-Code: The battle for efficient iteration in Go," and "Why Go Hides Spin Locks?" His blog (alexrios.me) is a goldmine on Go internals, systems programming, and tech leadership. 🔹 @mdelapenya will be the author of September guest post. He is an open source engineer at Docker and core maintainer of testcontainers-go, the library that's quietly become a the facto standard on how to write intengration tests in Go. Also, you can check out his blog, where is already talking about some internals of testcontainers. The goal is simple: make the scary parts of Open Source internals approachable, for interns, for seniors, for anyone who's ever typed a function call and wondered what really happens next.

I have a different take and don't want to start a debate, so I didn't post this. But I will reply that Go is just fine, the language is not losing its way (yet). But Go devs can lose Go's way if they treat every new feature as a new default. You're probably not the audience that feels the pain this feature is designed to solve. Use generics when they remove duplication or improve library boundaries. Use iterators where they make traversal cleaner. So just be skeptical of abstraction for its own sake.

@func25 It would be really interesting if you could explain your view on this one youtube.com/watch?v=WqSWZu…

Chapter 8 of The Anatomy of Go is now available. It discusses channels, timers, concurrency, goroutine creation and lifecycle, runtime startup, preemption, scheduling, I/O handling, the system monitor... and a bunch of other things. The book is now complete at 873 pages, and early access will be closing soon after the editing phase, (which may add a few more pages). As usual, here is an excerpt:

The VictoriaMetrics team is growing, and we're excited to welcome Jesús. Can't wait to see the deep technical and systems insights you'll share along the way.

@SoloCr33d Yes: bytesizego.com/books/anatomy-…. Feel free to reach out if you haven't received the latest version.

@func25 Is it available yet?

If your are interested in why VictoriaLogs is so efficient and fast, then take a look into these slides about VictoriaLogs architecture internals - docs.google.com/presentation/d…

Enums are good. I wish Go supported "real" enums. But union types are not, at least IMO. At the very least, I do not want union types in a TypeScript-ish form: func F(x int | string | []byte | io.Reader) { ... } This function accepts many unrelated shapes of input. Inside the function, you must figure out which one you got. It's never good to be too convenient. It loosens the language in a way that makes APIs harder to reason about. If Go somehow were to add union types, a more Go-ish version would be: type ParseResult[T] union { Ok(T) Err(error) } type Shape union { Circle(radius float64) Rect(width, height float64) } That is closer to an enum with payloads, or a sum type or tagged union or Rust-style enums. It keeps the set of cases closed and explicit. Go does not need "any value can be A or B or C" union types. Go would benefit from "this domain value has one of these known variants" sum types. You cannot pass values like in TypeScript: f(123) f("hello") You need to pass explicit variants instead, assuming Input is a tagged union: f(Input.Number(123)) f(Input.Text("hello")) More verbose but safer and stricter. See more at github.com/golang/go/issu… github.com/golang/go/issu…

"We weren't gambling on a new technology — we were promoting one we'd already been operating in production against our own workload, and that consistently outperformed Loki in our side-by-side testing on the kinds of queries we and our users actually run."

Something is seriously wrong with how people contribute to open source these days. People submit AI-generated code they clearly don't understand. When reviewers comment, they feed it back to the AI and submit again. The loop never ends. Low-effort PR requires extremely high effort to review. That math is never fair. You think this is how you build a reputation in open source? No, no, and no. You're just burning out maintainers. --- Use AI to understand the codebase instead. Ask it to explain things. Build your own judgment. It's ok to use AI as a tool for coding, but make sure you filter out any AI slop before submitting. You gain the skills. You gain the reputation. The project actually benefits. Is it that hard?

Code is becoming cheaper than ever, but maintainability is becoming more expensive than ever.

@HSVSphere @JustDeezGuy Fair enough, skill issue

@func25 @JustDeezGuy They really don't

A language in which “a lot of correctness around cancellation, task lifetimes, cleanup, error propagation, and backpressure is left to us, the programmer” cannot rationally be said to offer “simple, pragmatic concurrency.” Demand better. Because better is widely available.