In 2017, I started learning Go, mostly from curiosity. After working some years for Mattermost, I learnt enough to start sharing that knowledge with the community. Today I’m honored to share that I’ve been recognized as a @GoogleDevExpert in Go. This wouldn’t have happened without a lot of people involved in my own process, from the extremely welcoming Go community, to my companies, @kaleidosnet, @Mattermost, @ona_hq, and now @VictoriaMetrics, that has been always supportive and helping me to contribute back to the community. The GDE program is about sharing knowledge, so, there is not going to change much from my side, except that I'll have even more support to keep sharing with you what I learn in Go. #golang #GoogleDeveloperExpert #GDE #Go

My article about SIMD and Go is out! In this one I explain how one CPU instruction can work on 8 numbers at once, and how you can now use that from plain Go with the experimental simd/archsimd and simd packages. My intention with this post is to explain in simple terms how SIMD works at CPU level, to give you the mental model on how to use it, and then give you enough information about how you use it from Go to start working with it. You can read it here: internals-for-interns.com/po… #Go #SIMD

Please welcome to my blog Kemal Akkoyun, who works at Datadog and helps maintain otelc, OpenTelemetry's compile-time instrumentation tool for Go. Today he shows how to take part in a Go build without patching the compiler. The way in is `go build -toolexec`. Every compile, asm and link run goes through a program you pick, which gets the tool's path and arguments. From there, Kemal builds up step by step, first watching, then rewriting, and going down all the rabbit hole until he end up explaining how otelc does it. Read it here: internals-for-interns.com/po… #Golang #OpenTelemetry

I want to share something that the @VictoriaMetrics team faced recently that I think it is an interesting case. I'm communicating it, but the heavy lifting of this was done by other members of the team. The Go race detector found a race condition within the http client that catch us by surprise, so the team dig into it, and found two interesting things. If found this race in two places, one of the races, in our case, was not a problem, it could be, but not in our case, so we didn't fixed, but the second one actually was a bug, so we fixed it. If you want to know the details and understand what was happening, why not fixing it was the right choice for us, and why fixing the second one was needed, check out the blog post. victoriametrics.com/blog/htt…

This is my last article in my series about Kronk. In this one, I'm talking about the API, but more specifically about the streaming API and how it works and handle errors. This one end up being a shortest in the series, but I hope you enjoy it the same. Read it here: internals-for-interns.com/po… #Go

Just in case you are interested about how read ahead works in linux, I wrote this post: victoriametrics.com/blog/lin… In @VictoriaMetrics we really care about performance, so understanding how Linux is trying to help is important. But also It is important to help it to help us. 🙂

We just published a PostgreSQL 19 Interactive Tour. If you want to know what is comming in the new version of Postgres and want to play with it and see it in action, check it out here: victoriametrics.com/blog/pos…

The first @VictoriaMetrics meetup in Spain is going to be at October 2nd, in Valencia. If you are around and interested in observability it is a good opportunity to learn more and do some networking 🙂

Next week I'll be at @Percona Live in Amsterdam talking about how VictoriaLogs (from the @VictoriaMetrics stack) is able to ingest and query petabytes of logs in an efficient way.

I published today an article at the @VictoriaMetrics's blog, sharing the life of a metric. I think it is a good walkthrough about what happens to your metrics once they are scraped, until they gets discarded by the retention policy. victoriametrics.com/blog/the…

Today I'm publishing my article about the linux kernel modules. My approach, going through the loading process from the perspective to the .ko file. Understanding the sections inside, and how the kernel load it. There are some interesting things inside the .ko file: - .gnu.linkonce.this_module: a struct module laid out at build time representing the whole module. - .modinfo: a flat bag of key=value strings. license, vermagic, srcversion, depends, name. - __versions: a CRC per kernel function you call, so a function whose signature changed refuses to load. - The signature, glued on after the ELF ends, which is why no section ever mentions it. One of the thing that help me understand what is happening is to understand that the kernel is playing the role of the linker, it taking a binary with placeholder instead of function addresses, and fill those placeholders with the kernel functions addresses when the module is loaded. Read it here: internals-for-interns.com/po… #Linux #Kernel #Drivers