1. This can lead to programming errors if, e.g., a write is buffered in Golang and Close() flushes the buffer. Then you might not correctly write the file. (I k

1. This can lead to programming errors if, e.g., a write is buffered in Golang and Close() flushes the buffer. Then you might not correctly write the file. (I know that if you really cared, you should use fsync, but lost writes could happen in e.g. logging where you don't want the overhead of fsync but you would also like to see all log output, especially on program crash.) 2. I think this is a bigger deal than you are making it out to be. If open fails, how would you handle it without just exiting? I can't see a way of forcing finalizers to run. If you're distributing your Go binary to users, you may not have permissions to increase the allowed number of file descriptors. So your program no longer functions correctly. Example: A program that processes files in parallel. At any given time it might have 2 * num_cores files open, well below the default descriptor limit on most systems. If I rely on finalizers running, then I might have to exit if the time to process each file is sufficiently short. There is no way to fix this without instructing the user to increase their fd limit. This is bad. Alternatively, if I explicitly closed files, I would never exit.