Btw, for those that are interested, enum was added in Java5, the same time they added generics. It constituted the 3rd revision to the JLS.
> On Oct 24, 2018, at 11:39 AM, robert engels <reng...@ix.netcom.com> wrote: > > Also, I wouldn’t discount the ‘binary runs with the latest JVM’ doesn’t apply > to Go. > > As I pointed out in an earlier email, I think the future of Go is that the > shipped binary will be runtime linked against the standard library and > runtime. This is by far the easier way to deliver security patches. You will > probably pay a performance hit due to lack of inlining, but for a large class > of applications this would be a easy trade-off to make to simplify security > handling. > >> On Oct 24, 2018, at 11:26 AM, Burak Serdar <bser...@ieee.org> wrote: >> >> On Wed, Oct 24, 2018 at 10: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. >> >> You might be right on the history of "enum", but the point is that any >> time you add a keyword, something breaks. >> >> The point that old code can run on new JVM is inapplicable in my >> opinion when comparing Java and Go. >> >> Also, it may not always be a good thing to preserve backward >> compatibility. Opinions differ on this, but I think generics in Java >> is a convoluted piece of mess. >> >>> >>> On Oct 24, 2018, at 11:12 AM, Burak Serdar <bser...@ieee.org> wrote: >>> >>> On Wed, Oct 24, 2018 at 9:59 AM robert engels <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. >>> For more options, visit 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. -- 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.
