Thanks for your response Martin. I am glad you liked the article. I just wanted to reply quickly to parts of your comment.
I prefer to have the main function just call a second function that returns an int and pass that to os.Exit [1].
That’s also a nice pattern:-)
While I agree that commonly imported packages should refrain from using log.Fatal in their functions, I don’t think that removing it in Go 2.0 is a viable solution. It would probably break *a lot* of existing main functions for no real reason, since main functions won’t be imported by other packages.
I think Go 2.0 is still a few years ahead in time, but I don’t think it would be wise for Go 2 to restrict itself to the Go 1 compatibility promise. It is an idea to keep the investment in Go 1 though, as Dave Cheney has a nice article about. There is lots of ways that some sort of backwards compatibility can be kept when moving to 2.x. Before Go 1, the language could change dramatically from release to release, but we managed to cope because there was this wonderful tool called go fix, that would automatically upgrade your Go code to work with the next release. There is a strong indication that this could be part of the solution when moving to Go 2.
I assure you, removing log.Fatal, if the Go developers were to decide on that, would not be for no reason. While it is always up to the programmers to make mistakes, the language could help by making those mistakes harder to make. As long as log.Fatal works the way it does and stays in the library, it will keep being a potential pitfall for both new and experience Go programmers. As an example of how not to do this, C have a lot of deprecated functions that are no longer recommended to use, with new and better functions to replace them. This adds baggage to the language, and makes the language harder to use. C++ is much worse.
Finally, I think Go should aim not only to allow people to write good libraries, but also to write stable programs, and then what the main functions do matters.
