I didn't know that Ian had written this proposal so thanks for linking to it.
Although I haven't had time to read it in detail, I certainly agree with the tenor of what he's saying. I know more about C# than Java and the language team there have always been paranoid about not breaking compatibility with previous versions. Although lots of new keywords have been introduced since version 1.0, I think I'm right in saying that all of them have been 'contextual' and that no features have been removed from the language at all! Given that Go is quite a small language (much smaller than C#), I think that removing features from the language is simply not worth the hassle unless they are incompatible with new features or are downright dangerous. Removing the integer to string conversion would break a lot of code (I use it quite a lot myself to convert a byte or a rune to a string) and so I'd be disappointed if that were done. Sure it can be mildly confusing but that's all. I've also seen it suggested that complex numbers should be removed from the language and, whilst they may only be used by a minority of Go programmers, they do no harm, work just fine and are in C99 as well. If you moved them to the standard library then (unless operator overloading is introduced) they'd be far harder to use. Alan On Wednesday, October 24, 2018 at 4:59:34 PM UTC+1, robert engels wrote: > > I'd like to offer a few comments on Ian's > 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.
