I proposed that we should minify the verbosity in the main package a while ago as well.

main.main is invoked lazily on mobile platforms, it is more trivial to remove the boilerplate. I am not sure how it could effect the initialization on "desktop" mobile apps.

/cc @crawshaw @hyangah

And @nigeltao.

The problem is OS X, where Cocoa wants to use the first thread acquired by the process for its event pump. If you have a way to make "go build" work on OS X without app.Main, let's remove it, but it is not a feature I want to lose.

@crawshaw Is it just OS X, not also iOS?

Could it be as simple as automatically injecting this file into the build?

package main

import "runtime"

func init() {
    runtime.LockOSThread()
}

@gordonklaus One potential flaw with that solution is runtime.LockOSThread is not recursive (at least currently). So if the main goroutine then calls some function that uses runtime.LockOSThread() + runtime.UnlockOSThread(), the OS thread will end up unlocked.

@gordonklaus that's not enough, on OS X you need that code and you need to call [NSApp run] from that thread. That call blocks forever, so it needs to be inside the main function. Hence app.Main.

@crawshaw I see.

I think app.Main can still be avoided. It will just require some source manipulation, rewriting main.main. Maybe I'll take a crack at it tomorrow. Any advice is more than welcome 😄