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.adisuma...@gmail.com> 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 >> <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 > <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.
