What does a new user do if they do not have a github account?
I'd suggest

$ go new
Do you have a github account [y for yes, n for no, default no]?
no
There is no 'go' subdirectory of your home directory.
Would you like to create that to contain all your Go work? [y for yes, no for no, default yes]?
yes
Would you like to create a standard set of tutorial examples [y for yes, n for no, default yes]?
yes
Would you like to set the standard Go environment variables (GOROOT, GOPATH) [Y/n]?
yes
Would you like to add $HOME/go/bin to your PATH [Y/n]?
yes
...

or something along those lines. Maybe if you run Go without a GOPATH (or an inferrable GOPATH) it just suggests all the defaults in one go. Look in the home directory for .git* and .hg*, and work from there.

This is a nice idea to help people familiarize with the project, but it goes so far out of what the go program should be doing that I don't see a reasonable way to make it a subcommand.

Also, this might sound like nitpicking, but I mention it to illustrate the issues with the approach: in your example you show the current working directory changing from $HOME to some other location. A program (go) cannot do that. You'd need to make this a shell alias to work it like that, and this strongly points in the direction of an external tool, not something baked into the go program. In the original issue I provided an example of such an external program, that by way of some nasty tricks disguises itself a the go program. And even that implementation is not capable of doing what you show here.

@dr2chase Should probably make it more clear the url just is a namespace, but typically is some version control service, like github or bitbucket. If we wanted to sniff git username, that may be difficult for those of us who do not use github because while git config --list --show-origin shows my username, it does not show the host I use most.

@mem On windows we could use a wrapper batch script and call the command gonew and the user wouldn't see the difference in 99% of cases if we do it right. In *nix we would have a sh script that would have to be ran . gonew which is unfortunate, but the standard way. I think we would also need this to set the env vars anyway, but I'm not sure.

Additionally I do agree it is somewhat out of scope for the go command but I would always prefer not cluttering PATHs with 28 different executable for every tool, however we may have to add there if we want cd functionality.

I think we have different ideas of "new" user. I imagine people who would give you a blank look if you said "git" or "namespace". It's hard for me to imagine someone adequately competent at Git (i.e., more competent than I am) who would have difficulty getting started with Go.

@adg, thoughts on this? It's similar to your "workspace" idea.

It is indeed similar to my go workbench idea.

I think #17262 will probably make this less important. But it's a significant problem to solve, and there are many ways of looking at it.

1. There's a lot of room for helping users here. It's not clear that this is the right amount, nor that the right amount belongs squarely in the go command versus something else.
2. We don't know yet how much is left after we ship GOPATH=$HOME/go by default.
3. Ideally anything added to the go command would be helpful even once you become an experienced user, something power users would still reach for too. "go bug" is a good example: it helps new users but it's still useful once you know enough not to strictly need it. It's unclear this "go new" stays useful.

So it seems too early and maybe too much or too little. I think we need more information to make this more concrete.

Possible paths forward:

• Start a discussion on a mailing list like golang-nuts@ instead.
• Write a more concrete proposal of exactly what you want "go new" to do.