| ▲ | guappa 10 hours ago | ||||||||||||||||
> When did that become the golden standard? 30 years ago? > Signals and Backgrounding seem to be just developers that have little experience with that stuff. Yes, go developers have little experience. I see we agree. > What more are you expecting? Them to tell systemd they started. > I don't even know what you are referring to by the `old fork way` As I said, most go developers have little experience. I see you agree once again. The old fork way is the portable way to do it with whatever init system (systemd included). | |||||||||||||||||
| ▲ | Daegalus 9 hours ago | parent [-] | ||||||||||||||||
> 30 years ago? I have yet to find a developer, go or otherwise, that cares strongly enough about getopt outside the hardcore FOSS groups that pays attention to this. I know of getopt, and I don't follow it, because no one ever told me to was the golden standard, I was under the impression it was one of many ways, not the only way, especially if you work with systems like Windows at any point, that doesn't follow it either. I also personally don't like the getopt style > Yes, go developers have little experience. I see we agree. Or you know, they have no need for it, and don't implement it. You are conflating inexperience, with not caring about the thing you care about. > Them to tell systemd they started. Why? Very few services care about your init system these days. Like I said, containers have made it so you don't need to worry about it. I have dealt with many supervisors and init systems, and I have 0 interest in specifically adding code to notify them. At best I will add a network endpoint, and it is up to the unit file to poll for it, if it can. > As I said, most go developers have little experience. I see you agree once again. No, I am arguing that in modern day server dev, it is an unnecessary skill to learn, so they don't either learn it, while having plenty of other experience, or they specifically don't care enough about it for it to matter to them. > The old fork way is the portable way to do it with whatever init system (systemd included). This assumes you care about an init system at all. Like I mentioned previously, the majority of places Go servers run on are either in Containers, or microvms. The init system does not matter. So few go devs take the time to implement support. It is not lack of experience, it is priorities. I work in DevOps, ever since we moved primarily to containers, I have stopped caring about adding signal handlers, init system supports, etc. I write far fewer init files, be it unit files for systemd, or old school SysV stuff. It is an unnecessary set of features to add for projects that are internal, small, or run in containers. I am sure if a Go project gets big enough, it gets support for init systems, but those kind of projects are few, and init system support is an after-thought. If you are so big on FOSS standards, maybe open a PR and add the necessary sd_notify features. Should be only a few lines of code if you import https://github.com/coreos/go-systemd/blob/main/daemon/sdnoti... and call it. Most Go projects won't add this by default, because the use-case is infrequent for it for most places Go is used. Just like the article said a pro and con of the Go ecosystem is we don't need to worry about the rest of the dev world to gain the benefits of Go. So GNU/linux standards are not a priority. Especially with how easy it is to build cross-platform, using a Linux standard for all platforms is not perfect. Maybe take the time to be open minded instead of calling the entire Go dev ecosystem "inexperienced", it is simply the case of priorities and needs to the community, and when there is no need for doing the things you mention, they aren't added, even if the devs know about them. And I disagree that everyone should follow getopt, it is not the only way, and it is not necessarily the best way. | |||||||||||||||||
| |||||||||||||||||