4 ms·

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike t

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.

thanatos_dem 8y ago
> direct usage of syscalls instead of libc But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?
- _ph_ 8y ago
  No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.
paulddraper 8y ago
> direct usage of syscalls instead of libc Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?
- djur 8y ago
  It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard. MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries: https://github.com/golang/go/issues/16570 https://github.com/golang/go/issues/16570 Go has very recently started using libSystem (which is analogous to Linux libc or Windows CRT) on macOS to avoid this issue. On a more philosophical level, POSIX is defined in terms of a C standard library, and not using libc means Go doesn't support and/or must implement itself various features that are otherwise provided to POSIX applications by the system (like locale handling). Your mileage may vary in terms of whether that's a bad thing or a good thing.
  - paulddraper 8y ago
    > It is very common for language runtimes to link and depend on libc on Unix It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it. > MacOS doesn't guarantee backward compatibility for direct syscalls. Sounds like Go should use the stable API MacOS does offer. If the stable API is libSystem (different than libc), then so be it. But if we're talking about Linux libc, there's no reason for Go to use it. > POSIX is defined in terms of a C standard library Specifically POSIX.1 (not POSIX.2). Also, for what it's worth, POSIX compatibility falls short of Go's goals for compatibility. Specifically, on Windows. So I'm not sure what there is really to gain by following a different language standard for a different set of platforms that you desire to support.
    - johncolanduoni 8y ago
      It's also worth considering that none of the major systems are actually POSIX-compliant today. You're always going to need to make specific allowances if your standard library supports anything beyond the absolutely trivial even if you ignore Windows.
  - johncolanduoni 8y ago
    On glibc-based Linux you generally need to compile on a system running the oldest (or close to) version of glibc you want to support. I suspect this was the singlehanded reason for Go being built that way. That said, on macOS it makes a lot less sense because libSystem's compatibility guarantees work a lot like those of Win32, where you can safely compile on newer versions of the OS as long as you don't actually use features that are newer than your deployment target.
  - pjmlp 8y ago
    Windows syscalls are exposed via User32.dll, Kernel32.dll and friends, not MSVCRT.dll.
majewsky 8y ago
Same for me. I moved all my code into the GOPATH pattern after finding that I had 3 separate clones of the Linux kernel in separate places. (And not just for development, just for reading and grepping.) I made myself a helper tool for navigating the GOPATH: $ cg gh:torvalds/linux # cg = cd to git repo $ pwd .../src/github.com/torvalds/linux The code is at https://github.com/majewsky/gofu#rtree https://github.com/majewsky/gofu#rtree if anyone's interested.

thanatos_dem 8y ago

> direct usage of syscalls instead of libc But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?

_ph_ 8y ago
No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.

paulddraper 8y ago

> direct usage of syscalls instead of libc Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?

djur 8y ago
It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard. MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries: https://github.com/golang/go/issues/16570 https://github.com/golang/go/issues/16570 Go has very recently started using libSystem (which is analogous to Linux libc or Windows CRT) on macOS to avoid this issue. On a more philosophical level, POSIX is defined in terms of a C standard library, and not using libc means Go doesn't support and/or must implement itself various features that are otherwise provided to POSIX applications by the system (like locale handling). Your mileage may vary in terms of whether that's a bad thing or a good thing.
- paulddraper 8y ago
  > It is very common for language runtimes to link and depend on libc on Unix It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it. > MacOS doesn't guarantee backward compatibility for direct syscalls. Sounds like Go should use the stable API MacOS does offer. If the stable API is libSystem (different than libc), then so be it. But if we're talking about Linux libc, there's no reason for Go to use it. > POSIX is defined in terms of a C standard library Specifically POSIX.1 (not POSIX.2). Also, for what it's worth, POSIX compatibility falls short of Go's goals for compatibility. Specifically, on Windows. So I'm not sure what there is really to gain by following a different language standard for a different set of platforms that you desire to support.
  - johncolanduoni 8y ago
    It's also worth considering that none of the major systems are actually POSIX-compliant today. You're always going to need to make specific allowances if your standard library supports anything beyond the absolutely trivial even if you ignore Windows.
- johncolanduoni 8y ago
  On glibc-based Linux you generally need to compile on a system running the oldest (or close to) version of glibc you want to support. I suspect this was the singlehanded reason for Go being built that way. That said, on macOS it makes a lot less sense because libSystem's compatibility guarantees work a lot like those of Win32, where you can safely compile on newer versions of the OS as long as you don't actually use features that are newer than your deployment target.
- pjmlp 8y ago
  Windows syscalls are exposed via User32.dll, Kernel32.dll and friends, not MSVCRT.dll.

majewsky 8y ago

Same for me. I moved all my code into the GOPATH pattern after finding that I had 3 separate clones of the Linux kernel in separate places. (And not just for development, just for reading and grepping.) I made myself a helper tool for navigating the GOPATH: $ cg gh:torvalds/linux # cg = cd to git repo $ pwd .../src/github.com/torvalds/linux The code is at https://github.com/majewsky/gofu#rtree https://github.com/majewsky/gofu#rtree if anyone's interested.