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> 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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to