[satyanash]

The ruby one with the -run option is a bit nonintuitive in how it works.

  $ ruby -run -ehttpd . -p8000

The -r option requires un.rb[1] which is a file full of convenience functions, such as httpd in this example. Classic Ruby.

Given that go has popularized long args with a single hyphen (-name etc), it is easy to mistake -run as an option by itself.

[1] https://github.com/ruby/ruby/blob/master/lib/un.rb#L323

[BiteCode_dev]

> go has popularized long args, with a single hyphen (-name etc)

Why did they do that?

It took us 20 years to standardize on - for short and -- for long, with occasional finger rage on tar or find, and now this?

What were they thinking?

[unscaled]

My hunch is that Rob Pike, Ken Thompson, Russ Cox and the other Bell Labs alumni behind Go disliked GNU getopt-style flags, like they dislike a lot of other GNU and BSD decisions that "contaminate" the original philosophy behind Unix.

This overall attitude has led to many design decisions in Go, which define the language for better or worse. Statically-linked executables, for instance, contributed more than anything else to Go's popularity as a CLI tool language. Of course, the Bell Labs crowd was already highly skeptical of dynamic linking. See Rob Pike's opinion here: http://harmful.cat-v.org/software/dynamic-linking/

I say it's a hunch, but I think Russ Cox's following comments pretty much demonstrate this attitude against GNUisms and BSDisms: https://github.com/golang/go/issues/2096#issuecomment-660578... https://news.ycombinator.com/item?id=9207316

On the other hand, Russ clearly goes on to say they designed the flags not based on Plan 9 (which only had short single-letter flags), but on Google's gflags library: https://github.com/golang/go/issues/2096#issuecomment-660578...

In short, it's probably both:

- Innate distrust of all things BSD/GNU meant that the original Go team didn't feel they have to honor the established tradition. Just like dynamic linking, they believed that if there is something that GNU does wrong, they don't need to follow it just for the sake of keeping compatibility.

- Positive experience using gflags convinced the team that the gflags approach (single-dash long flags) is the best one.

I personally think they were wrong here. As Russ Cox himself clearly stated in response to all requests for fixing go flags: there are many libraries out there who implement GNU-style flags. What happened in practice is that most Go developers voted with their feet and chose a third-party flag module (even Google's own Kubernetes is using spf13/cobra). In the end, the Go flags package just ended up causing more confusion and didn't solve any of the problems (perceived or real) with GNU flags.

[BiteCode_dev]

Damn, a constructive and sourced answer. I wish I could upvote that twice.

[xaduha]

You can use -- or - as far as Go proper goes, doesn't matter in most cases. I think popular args libraries do that too, but there's a million of them, so some probably don't.

[masklinn]

> What were they thinking?

They were starting back from the 70s.

Also one more check for go being alt.history.java, this style is also the standard for Java tooling.

And Apple, I think.

[nonameiguess]

Also the standard for PowerShell.

[kazinator]

The XWindow system used -long -opts long before that.

[BiteCode_dev]

The XWindow system is a collection of the worse api in the world so it's no surprise.

But the vast majority of modern command line tools agree on --long.

[gimboland]

...aaaand it's more than 20 years old, so yeah, that kinda agrees with the point that it took us a long time to stop doing that because it's confusing.

[Sohcahtoa82]

I've always disliked not having a space between a -parameter and it's option. "-r un" is so much more readable and explicit than "-run".

Why do people not include that space? Certainly it's not to save the time of not hitting the spacebar, right?

[amarshall]

Permalink: https://github.com/ruby/ruby/blob/v3_0_1/lib/un.rb#L323

(Tip: can hit “y” on GitHub to change the URL to a revision-based permalink)