Agree on the industry dynamics observation--I remember too--but want to raise another point of view on 100% backwards compatibility: when Go was just a baby, in pre-1.0 days, there was exploration and new ideas. There was also "Go Fix" to rewrite "go of the past" as "go of today." This seemed genius to me in a systemic way; it meant that even bold changes could be easy and 100% reliable to change. It worked.
I'd like to see this mindset extended in two ways: to rewrite Go to new idioms and to rewrite Go 1 to Go 2. On the idioms front, if the standard library now appreciates read-from over write-to, then let's autoidiomatize it. If new Go 2 error checking is introduced, let's design the rewrite system and the feature in concert. I like this mindset and wonder if it could be sufficient to allow introduction of breaking changes. This is my question here--would rewrite fool assurances be enough to feel compatible in the way sought by the OP? Michael On Wed, Oct 24, 2018 at 9:40 AM robert engels <reng...@ix.netcom.com> wrote: > 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. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
