I did some research, you are correct that enum was not in JLS 1.0, nor was it a reserved word. Can’t find early later specifications to determine when it was actually added though.
I don’t know - I was against how generics were done in Java originally as well, but after using them for a while, it was easy, and the backwards compatible - even within the same code-base - was a god-send. Still, as I’ve mentioned previously, I have changed my thinking on generics in Go - I don’t think it needs it. I think minor tweaks to the error handling are appropriate and far more important (I would create an Exception interface that including stack trace information, or standardize the pkg/errors to allow more sophisticated/complex apps to have better handling). I also think 90+% of the use case of generics could be handled with changes to the make(), with : make(map or slice,options) where options were things like (ordered, synced, lockfree, descending), and the stdlib had implementations for these. Much simpler and fits with Go far better than generics. The maps and slices already have some magic, so just keep the majic there. I also gives an easy path to further implementation options, even people writing there own (more complex then generic code to write, to it would be rare anyway). > On Oct 24, 2018, at 11:21 AM, robert engels <reng...@ix.netcom.com> wrote: > > I think enum was a reserved word from the beginning - like goto - if not it > was VERY early on when it was added. Still, the code would of run on the > latest JVM, it might not of compiled. Outside of that possible case, I can’t > think of another keyword that has been added - maybe the recent addition of > ‘var’ - but don’t get me started on what it happening with Java now - I think > there are very different forces at work than the founding principles. > >> On Oct 24, 2018, at 11:12 AM, Burak Serdar <bser...@ieee.org >> <mailto:bser...@ieee.org>> wrote: >> >> On Wed, Oct 24, 2018 at 9:59 AM robert engels <reng...@ix.netcom.com >> <mailto:reng...@ix.netcom.com>> wrote: >>> >>> 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. >> >> That is not exactly true, is it? Any time a new keyword is added to >> the language something breaks. They added "enum" at some point, and >> all programs using enum as an identifier stopped compiling. >> >>> >>> 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 >>> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
