TL;DR: Recently we introduced extended Go Style Guide for the Thanos project , a high scale open-source distributed metric system where, with our large community, we take extra attention and care for the code quality.
Go + Distributed Systems = ❤️ Modern, scalable backend systems can be incredibly complex. Despite our efforts with other Maintainers, to not add too many features, APIs or inconsistencies to our projects like Prometheus or Thanos, those are still large codebases.
In this post, I would like to share what, in my honest opinion, a “perfect” maintainer of an open source software should do. Yes, no one ever will be perfect: we all have limited time, we all make mistakes and have some skills to learn. However, there is nothing bad in defining what we should aim for. (:
Some quick glossary for this (long) post:
Maintainer: Person responsible for the open source project development and community.
Available on Prometheus blog here .
EDIT (2020.12.13): From Go 1.16, Go on Linux moves back to using MADV_DONTNEED when releasing memory. However, this blog post still applies in terms of how to monitor memory consumption, although we should see less memory cached by Go runtime. See this issue .
TL;DR: Applications build with Go 1.12+ reports higher RSS memory usage on Linux. This does not mean that they require more memory, it’s just optimization for cases where there is no other memory pressure.
Available on Improbable blog here .
Available on Improbable blog here .
