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 <javascript:>> > 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 <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.
