There are fallacies in your arguments. First, you argue that Java is successful because it is backward compatible all the way back to version 1.0, both in source and binary compatibility. Therefore, if Go is to be just as successful, Go must do the same.
Second, you assume that people who disagree with you are in the "no backward compatibility" camp. Third, you rant about having to constantly update and rewrite your code prior to Java. Let's get back to those points. Java is not the only successful language. There are lessons we can draw from C and C++ too, which -despite their age- are still very relevant in today's world. To claim that Java is popular because it is backward compatible is just wrong. You are giving too much credits to backward compatibility. Java success is a combination of many things, including the heavy push from Sun which I mentioned earlier. Sun invested tons of money into Java. Putting aside the business aspects of Java, one technical merit of Java that you failed to mention as being contributive to its success is portability. In fact, Java is marketed as the "Write Once Run Everywhere" language. Although we know it is not 100% accurate, Java is -in a way- portable. It saves companies tons of money from having to write different code for different platforms. Your claim that the current Java is 100% compatible with Java version 1.0 is just wrong. Every time a new JDK is released, there is a compatibility document, which lists the various incompatibilities with the earlier versions. The binary compatibility part isn't relevant to Go. If you were to re-read the earlier posts, people who disagree with you don't necessarily advocate "no backward compatibility at all". They just don't agree that backward compatibility should go that far back. If Java don't even make a 100% compatibility guarantee with their version 1.0, why should Go? To me, Go 2 being backward compatible with Go 1 is still acceptable, but Go 11 being backward compatible to Go 1 is not necessary (You were using Java analogy: the current Java is 11 being compatible with Java 1). Last, I don't remember life was that difficult prior to Java. Backward compatibility was not Java invention. Many languages back then were already backward-compatible in a reasonable way. The major libraries were quite okay in my opinion. To me, the major value that Java brought was portability. On Sunday, October 28, 2018 at 11:47:19 AM UTC+7, robert engels wrote: > > I think arguing that marketing was the cause of the proliferation is not > accurate. Marketing helps push technology, see big mega company, but in the > embedded space since the consumer does not “know what’s in there” it > matters far less. Java proliferated substantially on technical merits. > Writing “UI interfaces” for desktop cable boxes and VCRs was too error > prone and costly (in time) - Java made this straightforward, if not trivial. > > There is a a reason that big mega company eventually copied Java’s design, > and platform for their own products - it was technologically superior to > what they had. > > I can only think of 2 major language changes in Java - generics/enums in > 1.5, and lamdas in Java 8, and both were backwards compatible from a binary > perspective and almost completely at the source code level. People keeps > saying “only trivial 1.0 programs would work”. That is just not true. If > you didn't use private apis (e.g. sun.*, or com.sun.*) it is going to > compile today and run today. > > As a person who lived through the constant update and re-write cycles of > the past, backwards compatability is not to be discounted. Pick your > favorite library, then imagine the API changed completely every 6 months, > would you still continue to use this library? You would either find > something else, or stay on the old version. > > I am not stating that Go proposes to change every 6 months - it is an > exaggeration (I seem to need to point these out) - but the acceptable > timeframe varies - based on resources, profit margins, etc. as to what > constitutes “worthless churn”. If Go is going to be used for > instrastructure systems (and OSes?) it needs a REALLY long shelf life - > these are not systems that are going to be continually changed… For > example, the Linux kernel is still C89 AFAIK… (commit > <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51b97e354ba9fce1890cf38ecc754aa49677fc89> > ) > > Btw, the additional keywords added after Java 1.0 through Java 11, 20+ > years later: > > enum strictfp _ (underscore) > > > > On Oct 27, 2018, at 11:08 PM, Henry <henry.ad...@gmail.com <javascript:>> > wrote: > > You need to remember that Sun spent a lot of money into Java marketing. > They aggressively pushed Java into every device, from servers to > refrigerators and toasters. No company to date has ever done what Sun did > with Java. So it is wrong to conclude Java is popular due to its technical > merits alone (or in this case, due to backward compatibility that goes to > back version 1.0 - which isn't true anyway unless it is a very simple > program). In fact, Java is now a highly complicated language rivaling C++. > They both have one thing in common: extensive backward compatibility. They > often implemented new features in a backward compatible way, creating > unnecessary complexity - which then accumulates as technical debts over > time. Backward compatibility is good, but it has to be reasonable and > limited. Otherwise, they will impose unnecessary constrains for the > language development. > > Having a compiler that can build older versions is good, but as I said, it > has to be reasonable. If the source's version is too ancient, it is easier > and simpler for the users to just download the older compiler and build. > There is no need for version annotation and you have less maintenance for > the current compiler. > > On Sunday, October 28, 2018 at 5:40:23 AM UTC+7, robert engels wrote: >> >> As others pointed out, this was not true when ‘enums’ were added, but >> still the Java compiler has always supported compiling using old version >> constructs. In the case of enums it was binary compatible. >> >> I think Ian’s proposal on the comment build flag to specify the language >> version is a good one. I think you might need to also be able to specify >> the language version in the mod file for legacy modules you don’t want to >> edit/maintain (as they wouldn’t have the per file comments either). >> >> On Oct 27, 2018, at 5:29 PM, hay <habiba...@gmail.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." >> I've concern about this. This kind of guarantee might prevent needed >> changes in the future version. In my opinion, backward compatibility >> guarantee by major version is best approach. For Go 2 and Go 3 developers >> should change their code if it breaks. >> >> -- >> 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...@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...@googlegroups.com <javascript:>. > 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.
