Jokes aside, I liked the idea of listing things by level of detail.
One related issue I run into all the time is how context gets lost when moving between layers. You start with host metrics, then Kubernetes wraps the host and overrides the tags, and suddenly you can’t filter host metrics by node anymore. Watch out.
My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.
I'm definitely in favor of not pessimizing code and assuming you can just hotspot optimize later, but I would say to avoid reusing objects and using sync.pool if it's really not necessary. Go doesn't provide any protections around this, so it does increase the chance of bugs, even if it's not too difficult to do right.
I mean, do it if it's worth it. But the parent seemed to imply everyone should be doing this kind of thing. Engineering is about tradeoffs, and sometimes the best tradeoff is to keep it simple.
Your initial judgement of using sync.Pool is quite overboard. The average go dev would wind up goroutines without much thought and pull in mutexes to avoid trouble. That's a hard thing to manage, using sync.Pool is comparatively easy.
For me it looks like the general sentiment is that go enabled concurrency, which should be leveraged, it also did simplify memory management, which should be ignored. But memory management has an direct impact on latency and throughput, to simply ignore it is like enabling concurrency just because someone said it's cool.
Everyone can talk and give opinions. The real question is if you can actually make a difference. I tell people there's a gap between knowing how to do something and actually doing it. And that gap is a big part of our engineering skills.
If I'm not going to change something, I'd rather not talk or give opinions.
I’m in the situation the article is talking about where I’m both suggesting advice and willing to do the work. But it requires me to have some allotted time and the boss says we don’t have the resources even 1 hour a week.
It’s like we’re moving chopped wood from the forest to the village and I suggest building a wheelbarrow but the boss says what we don’t have time for that we gotta move all this chopped wood. It’s crushing to have a job that could be very interesting but the tooling and processes sap all of that out.
> Any time you are making decisions based on information that you know at compile time, you could apply this technique
I’d go further. Most business requirements are known at compile time.
Take the simplest example, dispatching a function based on a condition. If A then do_X, if B then do_Y.
People often reach for elaborate design patterns, dependency injection, or polymorphism here. But why?
If the decision logic is static, don’t turn it into a runtime problem.
Inline the code. Move the ifs up. Write clear, specific functions that match your domain knowledge instead of abstracting too early…
I’ve been using a "no syntax highlight" theme for years. I recommend it. After a while, your brain basically turns into an AST parser and code becomes easier to read.
You clearly haven’t seen our Datadog invoice :)
Jokes aside, I liked the idea of listing things by level of detail.
One related issue I run into all the time is how context gets lost when moving between layers. You start with host metrics, then Kubernetes wraps the host and overrides the tags, and suddenly you can’t filter host metrics by node anymore. Watch out.
reply