Hacker News Reader

> So as it currently stands I have no idea what those modules are and what am I loading? vim25? Is that the text editor vim?

Take any of these imports, append it to https://godoc.org/, and see.

For example, github.com/vmware/govmomi/ becomes http://godoc.org/github.com/vmware/govmomi/ , which tells you:

    govmovi: A Go library for interacting with VMware vSphere APIs (ESXi and/or vCenter).

Everything underneath govmovi is subpackages of it, so `find`, `view`, `vim25/mo`, and `vim25/types` are all govmovi packages. You can also visit them on godoc to read documentation, if the code authors followed documentation best practices.

These are imports like in any other language. They are, however, nearly always based on a global URL, and thus have a godoc page that you can visit and read the docs for immediately. They are also always qualified, so if you wanna find all all uses of govmovi/vim25/mo, just C-f for "mo." in your codebase. No `from foo import *` equivalent exists in Go, which is one of my favourite features of this language.

Sure. Fair to say that godocs is to cpan of perl.

But Go doesn't present you the code on disk. I have to hunt somewhere else with a reference. With a library file, I know that prometheus::exporter::blah is related to the perl module prometherus, exporter subroutine blah

I need the code in front of me to understand how it's interacting; the whole github ruins that for me.

If you want to read the code, each godoc name can be clicked to directly redirect you to the source code of what you're looking for, eg. to a github page code viewer.

Depending on whether you use gomodules, GOPATH, or any other build system you also can find the files locally to grep through them or use your text editor to read them locally. You can also override import resolution to point to a fork (eg. of any module if using gomodules), if you want to test drive some local patches.

I do a _ton_ of code reading in my work, and I find using Godoc for that probably the best experience of any language (second only to maybe Haskell/Hoogle, but there you get much more difficult-to-grok-at-a-glance code).

> You can also override import resolution to point to a fork (eg. of any module if using gomodules), if you want to test drive some local patches.

So much overhead where time is limited. I shouldn't need to fork packages, I don't want to fork.

It's one `cp -r` and a 1 line change in go.mod [1]. You can also just `go mod vendor` to have all modules land in a `vendor/` directory when you can edit things as you wish [2].

[1] - https://golang.org/ref/mod#go-mod-file-replace

[2] - https://golang.org/ref/mod#vendoring

> But Go doesn't present you the code on disk.

Yes it does. You couldn't compile the modules if they weren't on disk :)

But only at compile time.

`go mod download`, if you're using go modules, will fetch you the deps.

This is no different, to me, than downloading a tarball of Python software with requirements.txt and not running setup.py or pip install. I don't understand the problem.

Right, then it could be I wasn't aware there is a "go mod download". If it actually gives me a file I can modify without having to create any repo, special things to apply the changes then that will assist me in the future.

Go isn't my thing and the less time I play with it, the happier I am. This is only my experience of it, and my experience is it acts friendly, but is a faff.

> the less time I play with it, the happier I am.

There lies the problem. If you don't want to invest the time to learn the tools then you can't really complain that your screwdriver is rubbish at hammering in nails. And it doesn't matter how easy or hard any programming language is, all languages will have a learning curve that people need to be prepared to undertake.

It's not that I don't want to, it's more I don't have the time to invest upon. I'd read all the national library books if I could, but I just don't have the time.

End of shift, I walk away from my screen and try to do something other than. I'm burnt out enough by the tech field as it is.

It seems to me that the problem here is your job, not Go. You could substitute Go here for any other language or technology that you don't know well and for which you're not given adequate time to learn the basics of, and you'd get the exact same result.

My job is solid. I have time to do such. I would rather just use my time available on have more pressing issues then a language I don't really want to use.

Sure knowledge is boss, but my job is fine. It's not the job at fault.

So it seems clear to me? You don't want to use the language, you don't want to learn the language, no-one is forcing you to use the language, then don't use the language.

What are your expectations? Is it that every language should be readable to people who know Perl? Is it that you shouldn't be reading or modifying the source code of open source projects? How could this work better in an ideal world? I am puzzled.

Why are you turning this in to such a pedantic thing? I am not a programmer. I am a systems administrator who administrates systems. Is that not easy to grasp?

When my job is 98.9% something else than programming, I'd rather be learning AI, Robotics, History, Psychics, Gardening, Glass Blowing than a language I'll never use.

I've explained it a case of "Can you get this to work" Yes/No. If no, I move on to something else. That's my line of work.

If you want me to monitor,configure,administrate something, then it should be simple. Presented to me in one folder with all packages not downloaded from some corporate hell-hole of a website because it's the norm for younger developers. Am I not allowed to have that opinion?

I will research on how to operate but that's it. Life's busy enough that I don't have time to further research on how to setup individual environments. I've just wasted 10 minutes typing this message to reply rather then configuring an openldap server for user authentication, Luckily I'm on lunch.

I'm not trying to be pedantic. Please do not assume bad faith.

I'm just trying to understand that worldview, which just seems drastically different from mine, even though we both seem to be generalists. If there is something that Go, or any other product, could do better to be better suited to your workflow, I would like to know what it is.

I don't write Perl, but if I had to qualify some piece of software that used it at work, I would make time then to learn as much of the basics of it that is needed to more easily get by. Even if it meant a day of reading Perl/CPAN docs to do 15 minutes of actual 'work', especially if the alternative is one or two days of blindly stumbling around to then not even be exactly sure if my 'yes/no' answer was correct. I don't even see much of a difference between learning something and just working with it - I can't imagine not having a browser window open with the docs/source code/whatever of what I'm currently working with.

In that way I've learned a fair bit of technologies I would have never touched otherwise, but now their knowledge, even at a surface level, is worth more than the sum of the products.

I mean no offense and sorry for my angst if it came that way. It's frustrating when I can't paint my view and then get battled to death because of it.

TCL.

TCL is the only language workflow that has worked for without any stress.

    proc SomeProcedure {variable} {
     Code it to do something for yourself }

save, run and it works. No need to include modules, no need to download anything. I use my own TK/Gui interface which does stuff for me to make my life easier. And if I handed it to you, it would be in one folder with all files present no dependencies required. However I understand life is not like that unfortunately.

> I can't imagine not having a browser window open with the docs/source code/whatever of what I'm currently working with.

I don't. If at any point I need source code, I'll download it locally and compile/run it first. Then edit it learn the logic and flow of the program. I'm in terminal 99% of the time, orchestrating systems ranging from FreeBSD to Linux and AIX, if a browser is open it's for Slack, emails.

I am someone who wants to type "man something" and get a man page of it. vim Library/file.pm and be able to view the code under the hood for that specific project. That's simplicity and that's how it should be -- The over-hassle of downloading from git, forking it, apply push,pull changes just isn't my street specially assuming my box I'm working with has internet.

The issue is you presented opinion as fact.

Opinion: I don't enjoy Go as much as Perl. [PASS]

Opinion: I'm more comfortable with Perl because I've spent more time in it. [PASS]

Both are perfectly acceptable.

However you made comments about objective truths that were incorrect:

Truth: Go doesn't download modules to disk. [FAIL]

For what it's worth, I really like Perl too. Us two are a dying breed in that regard. I was in two minds whether to reply because of that respect I have for fellow Perl hackers. But you kept repeating the same falsehoods as fact :(

Take your latest comment for example, you can bring up the Go docs for packages in the terminal as well:

    go doc $PACKAGE

So even there your Perl point is still equivalent to Go on an objective level. But I don't blame you for not liking/enjoying a language on a personal level.

My original discussion was of that I thought Go was very hidden under the hood. I gave an example and got mobbed for it. I replied with emotion and misunderstanding and here we are.

The main thing I was going on is "Here's a GitHub link, add it to your code and you have an instant logger thing". Magic in my eyes and this blinding light throws me off.

Unlike Perl where the code is in a .pm file in front of you. That was what I was trying portray.

I'm going to leave this discussion to rest as it's all went wrong anyway. Tomorrow will be tomorrow and this will all be forgotten in a day.

Thank you for your responses and have a good evening.

But the point is Go and Perl behave exactly the same way with regards to all the points you argued where they differ. Literally every point you've raised people have proven false. The problem here isn't that Go has some hidden magic, it's that you've never bothered to spend even 10 seconds checking if the packages were downloaded; instead inventing some wild, made up, theories about how things might work. This lead you to make some pretty daft claims like the Go compiler can build code that doesn't exist on disk (even as a non-developer sysadmin you must realise that's a pretty stupid claim to make?)

To be honest, I wonder if you're even using Perl correctly because if you're installing CPAN modules correctly then the .pm file is stashed away in an alternative directory that's looked up via an environmental variable -- just like with Go. The Perl module shouldn't be present in your projects workspace (and actually Go makes things easier than Perl here by allowing modules to be "vendored").

Go and Perl are very similar in a great many ways:

+ Both languages order modules/packages by directory hierarchies

+ Both languages look up module/package paths via special environmental variables

+ Both have CLI tooling to download and install modules/packages

+ Both have CLI tooling to read module/package documentation

+ Both are very much command line orientated

+ Both are imperative languages who's object systems feel like a half-arsed after thought and thus both really feel more at home writing functional code than OOP.

+ Both allow functions to return multiple parameters (a trait that's not too common outside of Perl and Go)

+ Both are strictly typed, support duck typing, and have a fairly limited type system.

+ Both treat arrays/slices and hash/maps as special types where the runtime has to have special code for handling them (ie you couldn't create a custom data type like a array/slice nor hash/map using Perl/Go's own standard library).

In fact the very reason I warmed to Go was because it felt like a nice hybrid between Perl and C. This was why I was so baffled when you said Go had some hidden behaviours under the hood when in fact managing a Go project is actually very similar to managing a Perl project.

Okay so you don't want to spend time learning new stuff but at the same time you don't want to be left behind.

You want a stagnant field. Sorry if I come across as too blunt, but you chose the wrong line of work if you don't like change. You'll still be able to work with the same old, boring but proven tech for the rest of your life, but face the fact that you'll be more inconvenienced by the reality you live in as time passes.

What? I want change, I like change. I understand change and I will learn change.

However when I have more pressing matters and when I am not requiring to use Go for my day to day life I have no purpose to put further education in to it other then enough to get by with.

You can import them at any time. Most people import early so that IDE's can inspect the packages (eg for completion tools etc).

Again, just like with Perl.

That's no different to importing a module in Perl. If you want to know what's in that module then you read the source of it.

> I understand all of that. Power_state, display the help, power status description etc, but prometheus.NewGaugeVec -- great. What is it? Where do I find this?

It's a function in the module `prometheus`: "github.com/prometheus/client_golang/prometheus"

It's the same thing as the following Perl code:

    use Prometheus;
    use Prometheus::Log;
    use Prometheus::Find;
    use Prometheus::View;
    use vmware::govmomi::vim25::mo;
    use mware::govmomi::vim25::types;

    my %prometheusHostPowerState
 = prometheus::NewGaugeVec(prometheus->GaugeOpts{
        "Namespace"  => $namespace,
        "Subsystem" => "host",
        "Name" => "power_state",
        "Help" => "poweredOn 1, poweredOff 2, standBy 3, other 0",
    }, @("host_name");

As you can see the code is actually really similar between the two languages in that regard. Bare in mind I'm not suggesting that the languages themselves are similar, eg how modules are created, methods written and arrays are handled are clearly different. But the concept of reusable imported modules and properties in a struct/hash are ostensibly the same.

Disclaimer: I've not written much Perl in the last 3 years so I might have gotten some of the syntax slightly wrong. But it should be close enough for demo purposes.

Then it would be fair to say I can't grasp the new-modern use of github module method then the traditional where prometheus.pm exists on disk and I can trace,trap and edit on the fly.

With the line above, prometheus::NewGaugeVec. I know it's related to the Prometheus module, NewGaurgeVec subroutine.

I'm not a programmer, I'm a systems admin who job is to take requests of such "we need a vmware exporter, I have this. Make it work".

The "new-modern use of a github module" is the same as for Perl. If a module isn't in CPAN you have to manually download and place in your project directory. Go just does this for you. And the module files in Go are on disk -- there's no way you could compile the project if half the source code wasn't on disk.

I think you'd probably have enjoyed Go more in the "old" days when $GOPATH was required and all modules were downloaded into your $GOPATH as it was more explicit were modules were and in a way it felt a little more like Perl with the file system being a more prominent part of modules. This was a very unpopular pattern for developers so things have moved on somewhat with modules now being pulled into a package directory. Personally I preferred the $GOPATH days too but it's fair to say the modules are still on disk.

You do not need to go down the Github rabbit hole. The symbol prometheus is from the package github.com/prometheus/client_golang/prometheus. Use go doc github.com/prometheus/client_golang/prometheus to read the documentation from your local copy of the package. Use go list -f {{.Dir}} github.com/prometheus/client_golang/prometheus to find out where your local copy is located. If there is only one prometheus.NewGaugeVec in your workspace, then the command go doc prometheus.NewGaugeVec shows the documentation for function and reports the package where it's defined.

Yes, it states the obvious, but I'm trying to point out what I mean. It's not always so golden as such.

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.

`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_depende...

> 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.