Phuong Le @func25

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.

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.

Jesús Espino @jespinog

2 weeks ago

Today is my first day at @VictoriaMetrics ! 🎉 Back to working on Open Source, on exactly the kind of deep systems project I've wanted for ages, performance, and understanding hardware, OS fundamentals. Lots to learn, and that's the best part. I'll be writing about what I learn

14 7 91 9K 4

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

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…

Sean Roberts @sean_j_roberts

a month ago

hot take: Go would be the greatest programming language on earth if it had enums and union types. they simplified their way into having to do really weird stuff just to represent reality. you should still probably use it though.

97 34 1K 150K 301

"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."

Zerops @zeropsio

2 months ago

The dedicated logger service inside every Zerops project is now using VictoriaLogs. - 100x more log retention - 3x faster queries - VictoriaLogs UI embedded into Zerops - Already rolled out to every existing project Full story below.

1 2 11 2K 2

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

@HSVSphere @JustDeezGuy Because you don't need that level of concurrency abstraction most of the time. context, waitgroup, errgroup, clear ownership patterns cover many common cases well

@raghavan_srini Agreed, though most backend systems people build aren't mission-critical at that level. Go ofc can, it just shifts responsibility to developers or to higher-level tooling

Go is not bad at concurrency. A more factual take is Go is excellent at making concurrency cheap, explicit, and approachable (and approachable, and approachable), especially for common backend patterns. But Go gives you relatively low-level primitives, a lot of correctness around cancellation, task lifetimes, cleanup, error propagation, and backpressure is left to us, the programmer. So the fair comparison is not "Go vs JVM, who wins?" It is: Go optimizes for simple pragmatic concurrency, the modern JVM ecosystem has stronger tools for structured and resource-safe concurrency. Which one is better depends on how complex the concurrency problem is. This is just a "depends on the problem" discussion.

James Ward @JamesWard

2 months ago

Generally developers think of Go as being great for concurrency. Its not. JVM approaches are vastly superior. And even some of the best in the whole industry when you include virtual threads, structured concurrency & Effects.

61 70 715 270K 462

@turbofish_pk I'm waiting right along with you :) It's currently going through an audit but I'm expecting it to be out sometime this month

@rahulyadavsep92 @sanskarpan It depends on the editor, but I expect it to be released this month

Go is simple, so I ended up writing an 865-page book about how it works internally, just to see how it maintains that simplicity 😇

@rahulyadavsep92 @sanskarpan That's weird, it should be 7 chapters, could you help @MattJamesBoyle?

@nowgoo I will try to push it in a couple of weeks

Chapter 8 of The Anatomy of Go is ready for review. It goes into concurrency, the Go scheduler, threads, the system monitor thread, goroutine preemption, what happens at startup, how channels work, how the select statement works, and how timers work behind the scenes, a lot and a lot, with visual explanations. This is the final chapter, it is near the end of the journey.