[hnlmorg]

The standard library isn’t going to change because of Gos backwards compatibility promise. Which is a good thing.

People can import their own flag parsing libraries, hence the HN submission we are discussing at the moment.

As for “talk is cheap” comment, I’ve written more open source code for working with software in the command line than most people. And that includes tools that parse other CLI tools and man pages to provide autocompletion hints. But that still doesnt mean that Go should make a breaking change to their standard library based on my personal preferences.

[naikrovek]

I didn’t say that you should aim to replace the existing package. You imagined that as a requirement.

How did log/slog appear if the Go standard library already has a logger and a backwards compatibility promise? Because you can add stuff without breaking backwards compatibility.

Go’s backwards compatibility promise is good in the short term, but if it has no expiration, that promise will be the rope wrapped around Go’s neck as it is pushed off a small platform and is left to dangle as the crowd watches.

Do you think that backward compatibility promise will still be upheld in 500 years? If you think not, then you agree that there is a line somewhere between 0 and 500 years and that on the other side of that line that promise makes no sense.

What about 50 years? Do you think in 50 years we’ll still have the same flag package in the standard library that we have today? I don’t. I certainly hope we don’t.

The more one clings to that backward compatibility promise, the more the backward compatibility promise strangles you.

I hope we incorporate lessons learned from Go 1 into some new version of Go, whatever its name is. I certainly DO NOT hope that we ignore what we’ve learned and fail to act because of a promise to never abandon the mistakes that have been made.

[hnlmorg]

The original points I make are still just as valid. Your counter, while not technically incorrect, doesn’t change the nature of the problem nor change my mind that a Go proposal is the right way to focus my energy at this point in time. Particularly when I’m already focused on several other open source projects in the same problem domain right now.

Time is a finite resource and there are already other packages out there that satisfy the problem, so why add to the noise?

One could flip the argument and say: if you’re so convinced that a proposal is the right course of action, then why don’t you create one yourself?

[naikrovek]

> if you’re so convinced that a proposal is the right course of action, then why don’t you create one yourself?

because I'm not annoyed by the existing flag package, and the people I was replying to are, that's why. that's why I suggested that they submit a proposal in the first place.

this is apparently a contest to see who can misunderstand me the fastest and you're all winners in this race.

[hnlmorg]

I think you’re the one who’s misunderstanding things here.

We aren’t annoyed. We said we dislike the one in standard library.

That’s also precisely why alternative packages exist. Like the one you’re commenting on right now. No proposal is needed.

I also admire your optimism regarding the ease in which people can push a proposal in Golang. ;) Gos famously hard in that regard.

[naikrovek]

you said you "really dislike gos style".

there is no better person to produce a proposal than the person who best understands why it isn't sufficient or is wrong in one or more ways.

I didn't say it was easy to guide a proposal from the proposal stage through to acceptance, or that I was optimistic about doing it. (you think I am misunderstanding you?) I merely feel like the people who like something the least are probably the most qualified to produce a quality proposal which has a chance at improving the landscape. that's all.

By the way, if i haven't said something outright, I did not infer that thing. Don't read between my lines, there's nothing there.

[hnlmorg]

> you said you "really dislike gos style".

Exactly. Dislike != annoyed

I can use a different package so what’s there to be annoyed about?

> there is no better person to produce a proposal than the person who best understands why it isn't sufficient or is wrong in one or more ways.

Dislike != insufficient

It’s a personal preference not a technical criticism.

> By the way, if i haven't said something outright, I did not infer that thing. Don't read between my lines, there's nothing there.

If you’re going to play the “you’ve misunderstood me” card then at least make sure you’ve understood people correctly yourself.

> I didn't say it was easy to guide a proposal from the proposal stage through to acceptance, or that I was optimistic about doing it

Changing the way the flag package would need to be changed to make myself (and others) happy couldn’t be done in a backwards compatible way. Thus it would have to be part of Go v2.0, which could be a decade away or might never happen.

And since all that the change would bring is an alternative, more GNU, way of parsing flags, it makes this hypothetical proposal a really low bar for improvement (unlike your other examples) thus this hypothetical proposal is unlikely to ever approved even if a hypothetical v2 of Go were to ever be released.

The whole premise of this changing is so remote that even suggesting I write a proposal in the first place is a massively optimistic take.

And for the record, I fully support Go not changing their behaviour here. Keeping the flags package as-is is the right thing for Go to do. So I wouldn’t even support my hypothetical proposal here even though I don’t personally like the existing flags package.

This might sound too nuanced for HN, but you can dislike something while still supporting it’s existence. Change here, in my opinion, would be worse than the status quo.