3 ms·

The one issue I had with Go when poking at it years ago was that it seemed to have fairly strict opinions on directory structure. It felt like if your project w

The one issue I had with Go when poking at it years ago was that it seemed to have fairly strict opinions on directory structure. It felt like if your project wants to use Go it had better be about Go. It was immediately in conflict with the other code I had going on in the library and where on my disk I wanted to put things.

fsmv 2y ago
This has been fixed with the newer modules system. You do have to name the folders the same as your packages but you can put the folders anywhere you want now.
- haiku2077 2y ago
  That naming requirement is only a requirement _within_ the source code. The folder containing go.mod can have any name.
MereInterest 2y ago
Not only that, but those extremely strict opinions on directory structure extend to your entire home directory. As an example, I wanted to install "gopls", the language server for go. There was a command that could install the dev tools, but it also generated a $HOME/sdk. With such a generic name in my home directory, there's not a chance that in 6 months time, I'd remember what it was for, why it was there, and whether it is safe to delete. No amount of changing $GOROOT could convince it to write into a different directory, nor was the go language server available through any other installer.
- evilduck 2y ago
  Containerizing every Go project helped me mitigate Go's opinions on my home directory but needing to do so in the first place was irritating.
  - MereInterest 2y ago
    That was my next step, but I had already spent an afternoon on it, so I ended up just making do without and using grep. (Partly because docker has it's own set of obnoxious quirks, as it assumes everything can and should be run as root. And rootless docker cannot coexist on a system with over-permissioned docker. I really need to switch over to podman at some point.)
tapirl 2y ago
Go has almost no requirements on project directory structure. Could you elaborate more?

fsmv 2y ago

This has been fixed with the newer modules system. You do have to name the folders the same as your packages but you can put the folders anywhere you want now.

haiku2077 2y ago
That naming requirement is only a requirement _within_ the source code. The folder containing go.mod can have any name.

MereInterest 2y ago

Not only that, but those extremely strict opinions on directory structure extend to your entire home directory. As an example, I wanted to install "gopls", the language server for go. There was a command that could install the dev tools, but it also generated a $HOME/sdk. With such a generic name in my home directory, there's not a chance that in 6 months time, I'd remember what it was for, why it was there, and whether it is safe to delete. No amount of changing $GOROOT could convince it to write into a different directory, nor was the go language server available through any other installer.

evilduck 2y ago
Containerizing every Go project helped me mitigate Go's opinions on my home directory but needing to do so in the first place was irritating.
- MereInterest 2y ago
  That was my next step, but I had already spent an afternoon on it, so I ended up just making do without and using grep. (Partly because docker has it's own set of obnoxious quirks, as it assumes everything can and should be run as root. And rootless docker cannot coexist on a system with over-permissioned docker. I really need to switch over to podman at some point.)

tapirl 2y ago

Go has almost no requirements on project directory structure. Could you elaborate more?