On Windows Golang defaults to install to C:\. Had no problems running it from Program Files instead. It's crazy that a new programming language cannot follow decades-old conventions!
Python did this until very recently too. Windows has a problem, because people expect to use those programs in the command line and the %PATH% has a size limit and is a bit difficult to set-up properly.
The sum of the length of all environment variables has to be below 32767 characters. That doesn't seem like a good excuse to save 14 characters by putting your program's folder in C:/ instead of C:/Program Files/
If you do deeply nested paths (as npm used to do) then you can run against the old MAX_PATH limit that limits paths to 260 characters, but the correct solution is to either choose a flatter directory structure or use the newer APIs that allow paths with 32,767 characters.
Steam is doing just fine writing into C:\Program Files (x86)\Steam\steamapps from an unpriviledged process. It just gives all users full rights over that folder. (whether that's a great idea is a different question, but UAC isn't a problem if you just set your access rights correctly)
Steam has definitely been handling Program Files wrong for as long as Program Files has existed. It's a marvel that there isn't more historic Malware intentionally targeting Steam install paths, though it looks like that storm is brewing on the horizon as I've seen references to such malware in the process of becoming a problem.
Steam should have worked to figure out a better approach to UAC years ago. At this point it is one of several big tech debt issues with Steam that has my confidence in Valve at an all time low as a consumer.
If the user never had admin priviledges then you can't install in C:\ either and the program should just install in AppData\Local (as my sibling poster correctly stated)
The problem there is "how lazy is VendorX"? With \Program Files\ Microsoft has a ton of top level ACLs to lock down access to the directories that everything just inherits by default. How much work does the OS need to do to allow something like "folders named `data` under \Programs\ have ACLs XData and `code` have ACLs YCode"? Does it need to watch for silly mistakes like Devs that localize `code` (`Código` for instance) or misspell it (`ocde` or `coode`)?
Also would make it easier to backup the program and its data or copy them to a new system.
But it seems because of the idea that some people may want to back up data and config separately, we end up with stuff scattered everywhere, with some even hidden away in the Windows Registry. Makes backups ridiculously complex.
I always thought it was because that space in “Program Files” was troublesome for a lot of programs, particularly command-line ones. IIRC, older versions of MinGW for instance would simply not work at all if installed in a path containing a space, because some of their startup scripts didn’t properly quote all parts of the path.
Default gopath was just a way to let newbies get up and running quickly; it originally required you to specify where to put it. I imagine they put it at ~/go so it would be glaringly obvious. Hopefully modules will render it all moot anyway.
They put it at ~/go because that's what every official document used as the example $GOPATH, before it had a default value, so it's largely just to minimize change from what they previously recommended.
That said, for something like source code, it makes sense to go into $HOME, so I don't understand this particular complaint the other poster made.
Other people's code shouldn't be in my $HOME if I didn't put it there explicitly. If it's part of the dependencies of a project, it should be either in a cache directory of that particular project, or in the cache directory of the build tool (that preferably conforms to XDG), like all sane build tools do. GOPATH is an incomplete (thus incorrect) solution to a problem that was being solved correctly and completely in other languages (like Ruby).
It's weird that the Go developers were working in such isolation that they didn't pick up on this. All programming languages that I know of that work on modern tooling (Haskell, Rust, Node.JS, even C#!) adopted the Ruby style dependency management when it turned out to be correct years ago.
In my comment I say that it's better than the way Go did it, and Go is switching to the Ruby style, so maybe you could add some kind of argument why it's actually not better than that in any other language?
I can't remember the last time I had a version management problem in Ruby, though the ecosystem is so stable right now not many backwards incompatible things happen any more.
