14 ms·

One reason not to go through libc is the possibility to create a pure Go userland like it’s done with the u-root project that is apparently in use at Google and

by hda111 6y ago

One reason not to go through libc is the possibility to create a pure Go userland like it’s done with the u-root project that is apparently in use at Google and resembles Busybox based systems with a memory safe language.

simias 6y ago
Unless you plan to never run anything but Go on your system you're going to need a libc at one point or an other. If anything this decision reinforces the NIH hypothesis for me. Almost like a prideful "NO C ALLOWED" stance which is not really pragmatic IMO. The only counterargument I can think off would be to remove the libc footprint for ultra-small, go-only distributions but I highly doubt that it's significant on any modern system (even an embedded one) and if you care so much about reducing the runtime footprint why would you go with a GC language in the first place?
- macksd 6y ago
  >> Unless you plan to never run anything but Go on your system That's actually exactly the use case for a lot of containerized applications written in Go. edit: I've worked on multiple applications like this and there's the odd service where you need some other dependency, and then that service has to start running on Alpine Linux or something. But if the majority of your many "microservices" are pulling in bits of userland from a distro, they stop being "micro" very quickly which is a big deal when there's a lot of them. It's far preferable in that architecture if the entirety of your userland is your own binary.
  - acoard 6y ago
    >Alpine Linux From their website:[0] >"Alpine Linux is built around musl libc and busybox" I could be off-base here, but it seems to me the better analogy would be some sort of "Go-Linux" that's like a Docker linux OS written entirely in Go. [0]: https://alpinelinux.org/about/ https://alpinelinux.org/about/
    - macksd 6y ago
      I wasn't making an analogy - I literally use Alpine Linux when I need some common *nix tools but I want something lighter-weight than the Docker images from more mainstream distros. musl libc and glibc aren't 2 fundamentally different things - the former is just a more permissive license and a lighterweight implementation.
- throwaway894345 6y ago
  In containers it’s entirely reasonable and desirable that you only ship your app with minimal dependencies. I suspect that the people who are grumpy about upstarts doing away with libc are also inclined to argue that containers are the work of the devil or some such.
  - macksd 6y ago
    >> containers are the work of the devil or some such And ironically it was the BSDs and Solarises of the world that had more fully developed similar concepts long before they were mainstream on Linux. I'm not terribly surprised by OpenBSD's stance here, though, and even though I'm more in the Go / Linux ecosystem I can't really argue - it's an unfortunate collision of very different philosophies.
macksd 6y ago
I've actually wondered if there would be demand for a Busbybox / Toybox clone built in Go for this reason. I have zero need for it personally, but I think it would be fun to make.

by hda111 6y ago

simias 6y ago

Unless you plan to never run anything but Go on your system you're going to need a libc at one point or an other. If anything this decision reinforces the NIH hypothesis for me. Almost like a prideful "NO C ALLOWED" stance which is not really pragmatic IMO. The only counterargument I can think off would be to remove the libc footprint for ultra-small, go-only distributions but I highly doubt that it's significant on any modern system (even an embedded one) and if you care so much about reducing the runtime footprint why would you go with a GC language in the first place?

macksd 6y ago
>> Unless you plan to never run anything but Go on your system That's actually exactly the use case for a lot of containerized applications written in Go. edit: I've worked on multiple applications like this and there's the odd service where you need some other dependency, and then that service has to start running on Alpine Linux or something. But if the majority of your many "microservices" are pulling in bits of userland from a distro, they stop being "micro" very quickly which is a big deal when there's a lot of them. It's far preferable in that architecture if the entirety of your userland is your own binary.
- acoard 6y ago
  >Alpine Linux From their website:[0] >"Alpine Linux is built around musl libc and busybox" I could be off-base here, but it seems to me the better analogy would be some sort of "Go-Linux" that's like a Docker linux OS written entirely in Go. [0]: https://alpinelinux.org/about/ https://alpinelinux.org/about/
  - macksd 6y ago
    I wasn't making an analogy - I literally use Alpine Linux when I need some common *nix tools but I want something lighter-weight than the Docker images from more mainstream distros. musl libc and glibc aren't 2 fundamentally different things - the former is just a more permissive license and a lighterweight implementation.
throwaway894345 6y ago
In containers it’s entirely reasonable and desirable that you only ship your app with minimal dependencies. I suspect that the people who are grumpy about upstarts doing away with libc are also inclined to argue that containers are the work of the devil or some such.
- macksd 6y ago
  >> containers are the work of the devil or some such And ironically it was the BSDs and Solarises of the world that had more fully developed similar concepts long before they were mainstream on Linux. I'm not terribly surprised by OpenBSD's stance here, though, and even though I'm more in the Go / Linux ecosystem I can't really argue - it's an unfortunate collision of very different philosophies.

macksd 6y ago

I've actually wondered if there would be demand for a Busbybox / Toybox clone built in Go for this reason. I have zero need for it personally, but I think it would be fun to make.