> Users care, because that's how all the other commands work. It's the standard whether you like it or not. Of course you can choose to do the snowflake CLI, but that doesn't really shout "experienced dev" does it?

I have never had a user complain about this. They just read the readme or the `help` and use it accordingly.

> oh lol… what % of go programs is used on windows? 1? 2?

I am sure it is quite a bit more than that, especially since I tend to see `exe` builds for most go tools I have used.

> You don't know how to do a thing that anyone writing a server process should know.

Oh I know it, I just don't think it is relevant for my day to day, or most of the go-made servers or tools I run.

Another thing that you seem to be assuming is that I am waiting for daemons to start. I used the term Containers instead of Docker specifically because the majority of them are in Kubernetes, or get converted to VMs for services like Fly.io. In those situations the daemon, or equivalent, is already running. I also use Podman, which doesn't have a daemon unless you need one.

And in the few cases where I would have needed to wait, I poll the docker unix socket for the /info path, and get the information that way.

> I have far more FOSS contributions than you do. Mostly in C/C++ or Python.

I never argued that, I have a paltry amount of FOSS contributions compared to most people interested in open source. I just said that if it matters so much to you that you are willing to label an entire dev community as inexperienced, and act all high and mighty about some standards that aren't seen as important these days, then you should teach us how to be better. Open that PR and show us the way. Obviously there is only 1 way to do things, and you are already well versed in it, guide us out of the dark hole we apparently live in.

> Maybe take the criticism instead of getting angry.

I am not in the least bit angry. I am discussing this, because I believe you are stuck in old ways and not adapting to the changes in the industry and development, especially in the areas where Go is used most, which is servers, devops, containers, and the like.

Also, I acknowledge there are industries, environments, etc that can't or won't use containers. But that is a small percentage of use-cases, and the engineers there are probably building things properly.

I will also never say no to implementing such a thing if I get an issue opened requesting it, a PR opened to add it for me, or the like. But I have not seen a need for it in years, both professionally or personally, to be added right away. And I feel like majority of Go devs have nothing against it, and would add it if requested. I know Miniflux for example, after their V2 rewrite into Go, added it 8 months later, due to a request. and have been maintaining/improving it since.

I had no clue how the sd_notify support was in Go in general, until this conversation with you. Not because I wasn't aware of sd_notify, I just never had to go looking for it or needed it. Took me 10 seconds to google it, find a library that saves me time, and I can add it to any server I need it in now. But I will do that if needed, not pre-emptively. Especially since 95% of the servers I make are for work, and dont need systemd. And personal stuff doesn't need it either. But if I opensource anything, and it is requested? I will add it without much fanfare.