5 ms·

> Having fewer keywords does make Go simpler to learn and simpler to read other peoples code I partly disagree. It might be easier for you with 30 years of exp

> Having fewer keywords does make Go simpler to learn and simpler to read other peoples code I partly disagree. It might be easier for you with 30 years of experience. Sysadmin with 8yrs of experience and having to manage operations utilizing Go is not easy. The code looks neat on the page; under the hood is really un-understandable at times unlike Perl, Ruby, TCL where the code is staring you in the face. The importation of modules off github is fundamentally wrong too.

hnlmorg 6y ago
> The code looks neat on the page under the hood is really non-understandable at times. Unlike Perl or TCL where the code is staring you in the face. Are you able to elaborate on this a little more? I love Perl and in fact that was my favourite language for a long time (despite all of its warts). But languages like Go are a lot more explicit that Perl so I'm not really sure what you mean by "under the hood" and "code is staring you in the face. > On vent: I also really loathe importing modules off github. I must admit that really annoyed me too but in fairness it's a pretty common pattern (eg brew, npm, etc). In a way Perl (CPAN) is an edge case rather than the norm. The difference is other systems add a shim around the code source even if they do still pull directly from (or from a cache populated directly from) Github et al
- doublerabbit 6y ago
  Sure. We use Prometheus exporters, most of the exporters are written in Go. And this is a snip from the vmware-exporter for our VMware estate. metrics.go The first throw was this: import ( "context" "github.com/prometheus/client_golang/prometheus" log "github.com/sirupsen/logrus" "github.com/vmware/govmomi/find" "github.com/vmware/govmomi/view" "github.com/vmware/govmomi/vim25/mo" "github.com/vmware/govmomi/vim25/types" So as it currently stands I have no idea what those modules are and what I am loading. Browsing each of those repos sure will tell me, but that's not my role. My role is to make X operational. And if that repo doesn't exist anymore and you go to compile, it fails. More overhead if I need to make changes to any of those modules. I would need to git clone it somewhere, make the change and then either recommit it to git, or do something to make it locally available. At least with NPM, CPAN they are local to the file system. So lets start: var ( prometheusHostPowerState = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Namespace: namespace, Subsystem: "host", Name: "power_state", Help: "poweredOn 1, poweredOff 2, standBy 3, other 0", }, []string{"host_name"}) I understand all of that. Power_state, display the help, power status description etc, however prometheus.NewGaugeVec -- Sounds great. What is it? Where do I find this? What module is this related too? That's where it falls down for me. I now have to duck in to the rabbit hole of github to find out where that function is phrased and in this sense "under-the-hood" could also count for library .pm files in perl, but now having to navigate GitHub really messes with my workflow.
  - sleepybrett 6y ago
    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/prometheus 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
    - doublerabbit 6y ago
      > 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.
      - BenTheElder 6y ago
        `go mod vendor` will populate all dependency sources into `./vendor/` in a modules project for easy grepping. Some projects still use this to ensure sources work airgapped as well. https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_dependencies https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_depende...
      - Seb-C 6y ago
        > 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.

hnlmorg 6y ago

> The code looks neat on the page under the hood is really non-understandable at times. Unlike Perl or TCL where the code is staring you in the face. Are you able to elaborate on this a little more? I love Perl and in fact that was my favourite language for a long time (despite all of its warts). But languages like Go are a lot more explicit that Perl so I'm not really sure what you mean by "under the hood" and "code is staring you in the face. > On vent: I also really loathe importing modules off github. I must admit that really annoyed me too but in fairness it's a pretty common pattern (eg brew, npm, etc). In a way Perl (CPAN) is an edge case rather than the norm. The difference is other systems add a shim around the code source even if they do still pull directly from (or from a cache populated directly from) Github et al

doublerabbit 6y ago
Sure. We use Prometheus exporters, most of the exporters are written in Go. And this is a snip from the vmware-exporter for our VMware estate. metrics.go The first throw was this: import ( "context" "github.com/prometheus/client_golang/prometheus" log "github.com/sirupsen/logrus" "github.com/vmware/govmomi/find" "github.com/vmware/govmomi/view" "github.com/vmware/govmomi/vim25/mo" "github.com/vmware/govmomi/vim25/types" So as it currently stands I have no idea what those modules are and what I am loading. Browsing each of those repos sure will tell me, but that's not my role. My role is to make X operational. And if that repo doesn't exist anymore and you go to compile, it fails. More overhead if I need to make changes to any of those modules. I would need to git clone it somewhere, make the change and then either recommit it to git, or do something to make it locally available. At least with NPM, CPAN they are local to the file system. So lets start: var ( prometheusHostPowerState = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Namespace: namespace, Subsystem: "host", Name: "power_state", Help: "poweredOn 1, poweredOff 2, standBy 3, other 0", }, []string{"host_name"}) I understand all of that. Power_state, display the help, power status description etc, however prometheus.NewGaugeVec -- Sounds great. What is it? Where do I find this? What module is this related too? That's where it falls down for me. I now have to duck in to the rabbit hole of github to find out where that function is phrased and in this sense "under-the-hood" could also count for library .pm files in perl, but now having to navigate GitHub really messes with my workflow.
- sleepybrett 6y ago
  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/prometheus 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
  - doublerabbit 6y ago
    > 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.
    - BenTheElder 6y ago
      `go mod vendor` will populate all dependency sources into `./vendor/` in a modules project for easy grepping. Some projects still use this to ensure sources work airgapped as well. https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_dependencies https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_depende...
    - Seb-C 6y ago
      > 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.