an easy way to hack on the 386 port

Does hacking on a port require being able to run the binaries, or just test that it compiles? If the latter, it'll still be possible to use something like linux/386 as a cross-compile target. (If the former, then that ability goes away when using macOS 10.15 or newer as this proposal stated.)

I opened a related proposal #34751 that's about darwin/arm.

keeping it around as an easy way to hack on the 386 port on his laptop

That sounds like a good use-case for virtualization..?

Brad, do you have an idea of the benefits of removing darwin/386? Alternatively, what are the costs of keeping it? I'm aware of:

• needing to have builders for it
  • keeping them functional (human time)
  • executing Go tests with them (CPU time)
• some amount of code to maintain and keep tests passing
  • do you know how much there is? is likely to be similar in amount as CL 199499?

Anything I'm missing?

Asking these questions in order to have more information and to be able to evaluate this proposal better.

Yes,

• builder time (and we have very limited Mac resources, so I'd prefer to not waste their time on ~useless build configs)
• code size (less code is better)

It's much less code & less weirdness than nacl. At least these files:

./runtime/rt0_darwin_386.s
./runtime/cgo/gcc_darwin_386.c
./runtime/signal_darwin_386.go
./runtime/defs_darwin_386.go
./runtime/sys_darwin_386.s
./debug/macho/testdata/gcc-386-darwin-exec
./debug/macho/testdata/fat-gcc-386-amd64-darwin-exec
./debug/macho/testdata/clang-386-darwin.obj
./debug/macho/testdata/clang-386-darwin-exec-with-rpath
./cmd/vendor/golang.org/x/sys/unix/zsyscall_darwin_386.1_11.go
./cmd/vendor/golang.org/x/sys/unix/asm_darwin_386.s
./cmd/vendor/golang.org/x/sys/unix/zerrors_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/syscall_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/zsyscall_darwin_386.s
./cmd/vendor/golang.org/x/sys/unix/zsysnum_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/zsyscall_darwin_386.go
./cmd/vendor/golang.org/x/sys/unix/ztypes_darwin_386.go
./syscall/asm_darwin_386.s
./syscall/zerrors_darwin_386.go
./syscall/syscall_darwin_386.go
./syscall/zsyscall_darwin_386.s
./syscall/zsysnum_darwin_386.go
./syscall/zsyscall_darwin_386.go
./syscall/ztypes_darwin_386.go

But also stuff in debug/macho, cmd/link, etc.

So, there are non-zero costs.

What are the reasons to keep it? The one reason we had is going away in the next ~month (when our primary runtime/compiler people update their laptops).

And in a couple more years it won't even be possible to run a darwin/386 binary on any supported Go build.

We discussed this today in the Go runtime & compiler meeting and nobody had any objections against removing it in Go 1.15, documenting that Go 1.14 will be the last to include it.

Change https://golang.org/cl/202018 mentions this issue: doc/go1.14: announce upcoming removal of darwin/386 port