godoc, same problem with any language that uses any kind of modules, you need to consult the documentation for that module. https://pkg.go.dev/github.com/prometheus/client_golang/prome... .. if fount that by googling `godoc prometheus newgaugevec` .. or you could just use `godoc`
Your argument seems to be, "I don't like reading documentation." Then by all means don't and write your own prometheus metrics module shrug
> Then by all means don't and write your own prometheus metrics module shrug
I'm a sysadmin, not a programmer. So I don't code for business operations. I compile them to make them work. I don't have time to read all the schematics of the application to make it work, but when it comes to perl, or TCL for that matter. All files are local, if my box has air-gapped and no access to github. Then what?
> Your argument seems to be, "I don't like reading documentation."
Not at all. I have limited time to spare on documentation. It's easier for me to read the code in front in practical form then it is to read documentation written on some wiki.
> I'm a sysadmin, not a programmer. So I don't code for business operations. I compile them to make them work.
Sounds like you have an organizational problem, not a programming language problem.
I would expect developers to provide you with an actual application or at least automated way to build it, and you to deploy and handle the given application.
Instead you have developers providing source code and you trying to understand how to make it work.
There are plenty of tools, methods and ways to get a repeatable build process, including docker, CI, bash scripts...
Even a README file can contain a valid and repeatable build process.
Even a process called 'ask to Robert how it works' would provide you with the information you need
It's hard to imagine that this is not scripted or at least documented somewhere.
Your argument seems to be, "I don't like reading documentation." Then by all means don't and write your own prometheus metrics module shrug