VictoriaMetrics now has a new account just for the technical side. If you're interested in database techniques, observability, and products explained visually, give it a follow:

Escape analysis in Go: stack or heap? youtube.com/watch?v=BanG_wLn… Tbh, every second is worth it, even if you don't know Go. I wish someone had taught me this when I was learning Go.

How Go maps work internally, explained simply. This time it's a video, not a blog post. youtube.com/watch?v=TdtNViWk… Enjoy, and let me know what you think :)

Some people think we can't learn software design with Go as it has no classes, no inheritance, no method overloading, etc But software design is about how we organize code, manage dependencies, and keep a change in one part from breaking another. E.g., encapsulation, it means controlling how other code can read or change our data. - In Java, we can use classes and private fields. - In Go, we can use packages and unexported names. Of course, they don't work the same way, but both let us choose what other code can access and what we want to keep inside our package or class. Polymorphism means the code can work with different implementations through an interface. Both Java and Go have interfaces but types in Go don't need a shared parent class, if they have the required methods, they satisfy the interface. DI or dependency injection is when we give a component what it needs instead of making it create that dependency itself. Like we can pass a database connection to a service when we create it. If the service accepts an interface, a test can pass a test implementation and we can do this with function parameters, I guess most of us have probably done it without knowing it was called dependency injection. Memory management is a separate (but interesting) topic. Go and Java use garbage collection, so we do not need to free heap objects ourselves. But we still need to understand how much memory our code uses, what happens when code shares data, and how keeping a reference to an object can stop the garbage collector from freeing it. Knowing syntax means we know how to write valid code. But more important is understanding the concept. I mean can we explain what practical problem it solves and when to use it? If we can solve the same problem in 2 different ways, which one is better and why? Actually starting with a complex, feature-rich language can be a good choice. Experience can't be taught, sometimes we need to spend time with that complexity before we can appreciate how simple the next language can be.

I just found an interesting Go repository: github.com/nikolaydubina/go-… If you are learning Go, spend some time here after the syntax tutorials. Learning how to check test coverage, compare benchmark results, and find bugs is also part of learning how to use Go.

You can choose the wrong backend if you only look at which one is faster in a benchmark, even when the results are accurate. The backend that is faster in the test may not be faster for your application. HTTP server performance depends on the complete request path - Routing, - middleware, - logging, - serialization, - external calls These all add work and 2 handlers can return the same responses but performing different things before sending them. Concurrency describes how much work is in progress at once. Increasing concurrent connections can increase throughput (e.g., how many requests finish per unit of time) while our server has limited capacity. But after a resource becomes saturated (reaches its capacity), additional concurrency can increase waiting time without increasing completed requests. A database pool with 100 connections does not mean your API can only handle 100 requests/sec. Each connection can be reused as soon as a request finishes using it. - If database queries finish quickly, the same connections can serve many requests in 1 second. - If queries take longer, connections stay busy longer, and new requests may have to wait for one to become available. Latency and errors give us information that throughput alone cannot. - Average latency can hide slow responses. - The p99 latency describes the point at or below which 99% of measured request latencies fall. - p100 is the maximum measured latency, the slowest request in your sample and gives us a very sensitive signal, since even a single unusually slow request can noticeably change p100. See xitter.cf/valyala/status/2091799… But none of these three tells you how many failed requests or timeouts you had. Memory usage can mean different things depending on what you are looking at. A high memory number does not always mean an application is wasting RAM - Live heap memory covers objects still considered reachable by the garbage collector. - Virtual memory includes address space the process has reserved or mapped. Some of that space may not use physical RAM at all. So seeing 4 GB of virtual memory does not mean the application is using 4 GB of RAM. - RSS shows memory currently in RAM. Some of it can be file-backed memory and is reclaimable, meaning the OS can free that RAM when needed and load the data again if the application uses it later. When the garbage collector reclaims objects, the runtime can keep that memory for reuse, so the memory usage reported by the OS may not drop immediately. So a high memory number alone does not prove waste or tell you how close the application is to OOM. It's better to always check which number you are reading, how much memory is reclaimable, and how usage changes as the application gets closer to its memory limit. If one implementation is faster in your test, that does not mean it will be faster when the workload or setup changes.