I tend to just not store them, even though I really like writing log lines, because while developing, it's a single process. I know what's going on and it has mail up. And then on top of that, you have profiling, right? And it's really easy to profile your applications using Go, but profiling is specific to resource usages, right? To actually debug and introspect and understand what's going on, maybe troubleshoot a problem, you actually need to combine all of them, right? Because every signal has its own use case. Yeah,

something that you cover in your book, Bartek. And by the way, congrats on the book. Thanks. I don't get a kickback from it. So I can just say it's available now. So if you want to learn about writing efficient Go, get it. In your book, I know that you mentioned this trade off between features and performance. And we've kind of talked about this when you sort of build up tech debt, as you go along adding features. Does this argument happen a lot where you're making the case to not have a feature because of the cost it's going to have? And then what about like product people or sales people or whatever else working there obviously incentivized really for the opposite thing, maybe? How does it go down?

Yeah, totally. It's kind of every day, every day question almost, right? Like, if we should invest in some amazing feature and especially deletion is an interesting one, right? Because we usually, at least in our ecosystem of like Prometheus and Thanos project as well as Mimi or and Cortex and Flair even and all those kind of like distributed systems or not distributed like time series database or sort of kind of like storages for different observability data, we kind of started in immutable storage. So once you kind of like try to delete something, it can cause problems. So and it can cause costs, right? So that's kind of like the question when we should add how much of the flexibility and deletion we should add and sort of those stories. And it really really depends. And kind of like what really helps is to have this budget of like how much cost you want to kind of add to the system. And you know, even like developing a feature is a cost like spending engineering time and testing and maintaining it. I really kind of try to recommend using the same pattern for like discussing, you know, how much you want to invest in kind of efficiency of something, if we should kind of make it faster or not, or we should maybe disable some feature because it was kind of slowing the system. This is exactly the same discussion as you would have should you add some feature, right? Because again, like it just was thinking about efficiency. It again, it's still kind of some cost. It will be some cost of like, you know, maintaining and so on. So everything ideally, ideally in the ideal world, you know, the cost of it. So you know, if deletion is kind of how much deletion request will cost, you know, kind of roughly CPU time. And if you have the capacity in your cluster, so this should be kind of like the core discussion to have. And if users are willing to pay for that, sure. But if for example, there is no, you want to kind of minimize the cost, maybe you should disable this feature. It really depends on what what user you are in and what project this is in. But generally, speaking about like data numbers is kind of helpful. And treating everything as the whole package, right? Not just features as readability and maybe complexity of the code or API or configuration, but also add efficiency on top like roughly the cost essentially just helps to make the decision, right?