4 ms·

That is an interesting experience, as I find the opposite true in most of my cases. And I am a go developer that likes go and use it for 95% of my coding, incl

That is an interesting experience, as I find the opposite true in most of my cases. And I am a go developer that likes go and use it for 95% of my coding, including MMO servers. I love programming languages and have used and dabbled in many. I still go to go. And many go tools I use tend to be pretty well written. But maybe this is just a sample size of 1 vs a sample size of 1 issue.

guappa 2y ago
From go programs at the very least I can expect they won't respect normal GNU getopt command line options, and work terribly with signals and going background in the terminal and so on. If it's a server, of course it won't support any way of communicating it's ready. Not the old fork way and certainly not the new sdnotify things.
- Daegalus 2y ago
  why would it have to respect GNU getopt? When did that become the golden standard? I never respect getopt because I really don't care about it and it has no bearing on anything I build. As long as they are documented under `--help`. Almost everyone uses Cobra from command-line options. And it is capable of doing getopt if you want, but I don't see why it would be a requirement. Signals and Backgrounding seem to be just developers that have little experience with that stuff. I can't remember the last time I did any sort of signal handling to do anything specific. And I haven't had issues with backgrounding, but that might be just the tools I use and the infrequency of backgrounding that I do. Most servers I interact with or work on have some sort of `health` api endpoint to get that status because most servers in go are HTTP. What more are you expecting? I don't even know what you are referring to by the `old fork way` but I will agree most don't use sdnotify, as that makes the assumption you are running Go on something that handles systemd notifications. I am fairly certain a majority of Go servers run in a container, specifically an Alpine, distroless, or scratch container. So communication would be over stdout or some kind of API endpoint, be it HTTP, GRPC, or any other TCP/UDP endpoint.
  - guappa 2y 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 2y ago
      > 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/sdnotify.go 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.

guappa 2y ago

From go programs at the very least I can expect they won't respect normal GNU getopt command line options, and work terribly with signals and going background in the terminal and so on. If it's a server, of course it won't support any way of communicating it's ready. Not the old fork way and certainly not the new sdnotify things.

Daegalus 2y ago
why would it have to respect GNU getopt? When did that become the golden standard? I never respect getopt because I really don't care about it and it has no bearing on anything I build. As long as they are documented under `--help`. Almost everyone uses Cobra from command-line options. And it is capable of doing getopt if you want, but I don't see why it would be a requirement. Signals and Backgrounding seem to be just developers that have little experience with that stuff. I can't remember the last time I did any sort of signal handling to do anything specific. And I haven't had issues with backgrounding, but that might be just the tools I use and the infrequency of backgrounding that I do. Most servers I interact with or work on have some sort of `health` api endpoint to get that status because most servers in go are HTTP. What more are you expecting? I don't even know what you are referring to by the `old fork way` but I will agree most don't use sdnotify, as that makes the assumption you are running Go on something that handles systemd notifications. I am fairly certain a majority of Go servers run in a container, specifically an Alpine, distroless, or scratch container. So communication would be over stdout or some kind of API endpoint, be it HTTP, GRPC, or any other TCP/UDP endpoint.
- guappa 2y 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 2y ago
    > 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/sdnotify.go 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.