5 ms·

Your blog post has some assertions that are either overbroad ("No type inference.") or just unsupported ("The whole design of GOROOT/GOPATH is completely broken

Your blog post has some assertions that are either overbroad ("No type inference.") or just unsupported ("The whole design of GOROOT/GOPATH is completely broken".) Everyone is welcome to their opinion, but it'd be nice if they actually supported it with some explanation if they want to bandy it about in public.

rwmj 13y ago
Well you can't call 'var' type inference (Edit ':=' .. it's still laughable compared to real type inference). But I'll explain the GOROOT stuff in a bit more detail ... Basically the way it's set up prevents golang modules from being packaged up for Linux distros. There are two main problems. Firstly the 'go' utility tries to recompile installed modules, which isn't going to work as those modules are in files and directories owned by root and 'go' is not running as root. By very carefully setting up timestamps it's usually possible to avoid this, but it's fragile. Secondly if you do install a golang package, you can't compile an alternative copy in GOPATH, because the one in the (root-owned) GOROOT overrides it. Which is dumb and backwards.
- burntsushi 13y ago
  There are a myriad of possibilities that await you on the Archwiki. [1] Also, you should not be installing third party packages in `GOROOT`. If you do, then yes, you're going to be in some trouble. [1] - https://wiki.archlinux.org/index.php/Go_Package_Guidelines https://wiki.archlinux.org/index.php/Go_Package_Guidelines
  - rwmj 13y ago
    That web page summarises how we package golang libraries so far, and it's (a) fragile and (b) doesn't let people install their own development copies of libraries, as I said in the gp post.
    - burntsushi 13y ago
      > doesn't let people install their own development copies of libraries Then maintain two different and distinct `GOPATH` directories. One for development libraries and one for other stuff.
- mseepgood 13y ago
  > Well you can't call 'var' type inference 'var' is not the type inference, ':=' is the type inference.
  - pcwalton 13y ago
    It's not HM-style type inference, which is presumably what the parent comment was referring to.

rwmj 13y ago

Well you can't call 'var' type inference (Edit ':=' .. it's still laughable compared to real type inference). But I'll explain the GOROOT stuff in a bit more detail ... Basically the way it's set up prevents golang modules from being packaged up for Linux distros. There are two main problems. Firstly the 'go' utility tries to recompile installed modules, which isn't going to work as those modules are in files and directories owned by root and 'go' is not running as root. By very carefully setting up timestamps it's usually possible to avoid this, but it's fragile. Secondly if you do install a golang package, you can't compile an alternative copy in GOPATH, because the one in the (root-owned) GOROOT overrides it. Which is dumb and backwards.

burntsushi 13y ago
There are a myriad of possibilities that await you on the Archwiki. [1] Also, you should not be installing third party packages in `GOROOT`. If you do, then yes, you're going to be in some trouble. [1] - https://wiki.archlinux.org/index.php/Go_Package_Guidelines https://wiki.archlinux.org/index.php/Go_Package_Guidelines
- rwmj 13y ago
  That web page summarises how we package golang libraries so far, and it's (a) fragile and (b) doesn't let people install their own development copies of libraries, as I said in the gp post.
  - burntsushi 13y ago
    > doesn't let people install their own development copies of libraries Then maintain two different and distinct `GOPATH` directories. One for development libraries and one for other stuff.
mseepgood 13y ago
> Well you can't call 'var' type inference 'var' is not the type inference, ':=' is the type inference.
- pcwalton 13y ago
  It's not HM-style type inference, which is presumably what the parent comment was referring to.