I'd like to offer a few comments on Ian's https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md <https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md>
Since the author admits the least amount of experience with Java, maybe my facts, and many opinions, might offer some insight. If you head back to the genesis time of Java, there was a dominant tech company that produced the dominant OS and associated development tools. It was a “their way of or the highway” scenario. Almost like clockwork, every OS change was not backwards compatible, at least from the point of, if you wanted to use the new feature in the latest OS, you needed to use new APIs for even the “old stuff”. So development teams and businesses were in this continuous cycle of rewriting the same code for a new API, every few years, all without delivering any new value. Couple this with, you had to be “current” in order to get “support”, and it’s easy to see the strangle hold they had on an industry. When Java came along there was a heavy sigh of relief by ISVs that understood write-once, and it will continue to work even as mega company released new OS versions and APIs - the burden was on the JDK/JRE implementation to make sure it worked - not the business. The write-once run “anywhere” was icing on the cake - it opened doors to some markets very cheaply. To this day, you can take a “binary” written for Java 1.0 and it will run under the latest JRE. You can compile Java 1.0 source code with the latest compiler. This is an amazing accomplishment that can’t be understated. Over the years, with the benefit of hindsight, many of the Java APIs were deemed insufficient, or better designs emerged, and they were deprecated, with the warning, "may be removed in a future release”. To my knowledge a deprecated API in the stdlib has never been removed. The “deprecation” label is more of a “hey, there are better ways of doing this, and you should use them…”. I think Go would be best served by ensuring that any future release is 100% backwards compatible with previous releases. This is the number one aspect of Java (IMO) that lead to its success - it drastically reduced the churn/expense of delivering software. Businesses like this…. Developers like this... In the end, if Go can deliver on the cross platform (some of the OS specific APIs were a bad choice in some ways IMO, although it is not a deal breaker), and the 100% backwards compatibility, I don’t see any reason why Go couldn’t become as ubiquitous as Java. I believe in the end there will two languages left standing. Java for enterprise apps, and Go for system tools, services, and even OS building. It is nearly 2020 - manual memory management is done, dynamic languages are done... Even in the browser, I think Google has figured out what Java folks knew 20 years ago, JS is a mess, and having a VM in the browser is the way to go. WebAssembly is the poor mans Java applet. We’re coming full circle… So to sum up, 100% backwards compatibility is a key to Go’s dominance moving forward, again IMO ) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
