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.
