Some days ago I got a new intriguing issue opened for gopium which is one of my projects, I maintain. In a few words: fieldalign linter in govet complained about unoptimal fields with pointer data ordering produced by gopium memory packing strategy. On a surface, the issue looks strange. Why would ordering of fields containing pointers inside structure matter? Many developers know for the fact that structure alignment and field order matters in a number of situations....

Lately I’ve reached to Concepts and Algorithm Intuition episode of CppCast in my podcast listening routine. Which also expanded into watching two subsequent CppCon 2019 talks Algorithm Intuition (part 1 of 2) and Algorithm Intuition (part 2 of 2) given by Conor Hoekstra. While the ideas and lines of thinking behind “Algorithm Intuition” listed there are sane. I still got an odd aftertaste after going through them. In a few words, the author makes a claim that C++ STL takes on algorithms and data structures fields is the right one....

Some time ago, routinely jumping through blogs of people I consider interesting on github, I found one great blog focused on Rust and its surroundings. Frankly, I don’t care about Rust that much right now. Mostly because I don’t like the ideas behind the language and one, which is even more important I haven’t even tried to write something meaningful using Rust. Neverthelse, it’s always beneficial to read different opinions on the topics that you both know well and superficially....

Recently, I stumbled upon an article from Google engineers that describes ways of reducing tail latency used inside Google. Among obvious methods like: managing background activities and adding priorities queues on various system levels. There were also listed multiple methods, efficiency of which might look less evident at the first glance. Notably, in “within request short-term” section: Hedged requests. A simple way to curb latency variability is to issue the same request to multiple replicas and use the results from whichever replica responds first....

As the proposal of adding generics in go has finally came to its endspiel and has been accepted. I want to add my two cents on this event and explain why I think that generics is a bad idea how to introduce a meta programming to go. Origins The history of generics in go is truly amazing. The ultimate answer to the question of having generics in go has evolved together with the language....

Lately, I discovered one great tech blog https://tpaschalis.github.io. One of the articles that caught my eye was amb operator in golang. In my opinion, ambigious operator is brilliant concept in scope of elegant functional programming. Ambiguous operator is defined by its author John McCarthy as Ambiguous functions: Functions whose value are incompletely specified. May be useful in providing facts about functions where certain details are irrelevant to the statement being proved....

Recently, I’ve finished my reading of “Software Engineering at Google” book. Despite the fact that this book contains considerable amount of: information duplicity, obvious advices and quite generic explanations. I still can suggest this book to anyone interested in understanding the modern Software Engineering industry. Although be advised that book doesn’t go very deep with any given topic. Rather, it’s just quite nicely composed collection of easy to read and understand thoughts from Google engineers....

According to go survey 2020, gomod has finally won long disputes around dependency management in go: “Go modules adoption is nearly universal with 77% satisfaction, but respondents also highlight a need for improved docs”. This is not surprising at all, as it is indeed a solid tool, but even more importantly, included into default go distribution as the official dependency management tool. With that said, gomod is not ideal (as any other complex tool) sometimes you can stumble upon some controversial decisions or need to know some internal implementation details to use it properly in some less common setups....

Go zero values Zero values is an extremely useful feature of golang, you can read nice detailed article about why they are so important. They are not only making day to day programming simpler but also save everyone from whole layer of “uninitialized variable” errors specific to languages like C. Personally I think that it would be beneficial if go could provide us with more useful safe zero value for all builtin structures....

Memory tracing retrospective On the dawn of computer era, every allocated piece of memory was properly accounted by a programmer, it was not possible otherwise as memory was limited and precious fundamental resource. Memory is no less fundamental resource nowadays but with its exponential growth per single machine; trend of adding more high level memory management abstractions bloomed. In languages like C it’s rather easy to calculate exact amount of memory allocated (you fully control all heap allocation by yourself), on the other hand it’s not that simple in languages like Go that are hiding memory management details inside runtime abstractions....