Re: [go-nuts] Re: Go 2 Proposal Comments

[Robert Engels]

Everybody is always aging, nothing to read into. 

Sent from my iPhone

> On Oct 28, 2018, at 8:51 PM, Scott Cotton  wrote:
> 
> 
> 
>> On Monday, 29 October 2018 00:25:04 UTC+1, kortschak wrote:
>> Prior to about a couple of months ago, it was very rare to see anything 
>> here about exciting additions to the language from aging gophers. I 
>> think it's probably fair to say that many of us were quite happy with 
>> that situation. 
> 
> Not sure myself as an aging gopher how to interpret that.  
> 
> Also, Robert's comments on Ian's proposal, the subject of this thread, is 
> about how to move the language forward 
> as it changes. The discourse has digressed a bit, and it would be nice to 
> stay on more topic, but it happens.  Not sure
> myself how or if the question of happiness with or without aging gophers is 
> relevant.  
> 
> Scott   
> 
>  
>> 
>> On Sun, 2018-10-28 at 07:31 -0500, Robert Engels wrote: 
>> > Next thing Gophers will be crying for is lambda syntax... just wait. 
> 
> -- 
> 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.

Re: [go-nuts] Re: Go 2 Proposal Comments

[Scott Cotton]

On Monday, 29 October 2018 00:25:04 UTC+1, kortschak wrote:
>
> Prior to about a couple of months ago, it was very rare to see anything 
> here about exciting additions to the language from aging gophers. I 
> think it's probably fair to say that many of us were quite happy with 
> that situation. 
>

Not sure myself as an aging gopher how to interpret that.  

Also, Robert's comments on Ian's proposal, the subject of this thread, is 
about how to move the language forward 
as it changes. The discourse has digressed a bit, and it would be nice to 
stay on more topic, but it happens.  Not sure
myself how or if the question of happiness with or without aging gophers is 
relevant.  

Scott   

 

>
> On Sun, 2018-10-28 at 07:31 -0500, Robert Engels wrote: 
> > Next thing Gophers will be crying for is lambda syntax... just wait. 
>

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Gerald Henriksen]

On Sun, 28 Oct 2018 09:31:30 -0500, you wrote:

>To clarify, think of the performance improvements in the GC in Go from 1.1 to 
>1.11. Amazing. But you only get these via recompiling which is a barrier. Many 
>java installations frequently get performance improvements with no code 
>changes or recompilation. This is why I’ve been investigating packaging Go 
>binaries with dynamic linkage to the runtime and stdlib. 

That's a bit misleading - those peformance improvements do come from
recompilation it's just that you don't see it (other than a slow first
start) given that each new JVM will recompile the bytecode.

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Dan Kortschak]

Prior to about a couple of months ago, it was very rare to see anything
here about exciting additions to the language from aging gophers. I
think it's probably fair to say that many of us were quite happy with
that situation.

On Sun, 2018-10-28 at 07:31 -0500, Robert Engels wrote:
> Next thing Gophers will be crying for is lambda syntax... just wait.

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Robert Engels]

It’s in its early stages but if I understand my conversations with Ian 
correctly, he says this is already available for the stdlib. I agree that 
dynamically linking to the runtime is more difficult but given some 
restrictions it might work. 

Sent from my iPhone

> On Oct 28, 2018, at 1:01 PM, Scott Cotton  wrote:
> 
> 
> 
>> On Sunday, 28 October 2018 15:31:54 UTC+1, Robert Engels wrote:
>> To clarify, think of the performance improvements in the GC in Go from 1.1 
>> to 1.11. Amazing. But you only get these via recompiling which is a barrier. 
>> Many java installations frequently get performance improvements with no code 
>> changes or recompilation. This is why I’ve been investigating packaging Go 
>> binaries with dynamic linkage to the runtime and stdlib.
> 
> In what sense are you or have you been investigating?
> 
> The things I see which are blockers to this are
> 1.  The compiler/runtime are intimately linked, and free to evolve over time. 
>  So the runtime API to the compiled code isn't even fixed in a way that 
> dynamic-linking would work across versions.
> 2. The runtime itself manages stacks, so there would need to be some 
> assumptions about operating context when it could be linked.  For example, if 
> it were linked while the stack is high/deep, then where would the runtime put 
> the stack?  where would the runtime system stack be placed?
> 
> It's very different than applying a runtime to byte code.
> 
> Scott
>  
>> 
>> 
>> Sent from my iPhone 
>> 
>> > On Oct 28, 2018, at 9:23 AM, Robert Engels  wrote: 
>> > 
>> > Cool. Not sure why the JVM is not applicable to the discussion as it 
>> > normally ensures binary compatibility as languages evolve. 
>> > 
>> > Sent from my iPhone 
>> > 
>> >>> On Oct 28, 2018, at 9:16 AM, Gerald Henriksen  wrote: 
>> >>> 
>> >>> On Sat, 27 Oct 2018 14:33:32 -0500, you wrote: 
>> >>> 
>> >>> What exactly are you referring to? I wasn’t aware of Android no longer 
>> >>> being Java. 
>> >> 
>> >> At Google I/O 2017 the Android team announced that Kotlin would be 
>> >> supported as a first class language along with Java, including full 
>> >> support in Android Studio. 
>> >> 
>> >> While Android will likely never get rid of its Java base, developers 
>> >> have been switching to Kotlin due to the advantages it offers over 
>> >> Java.  Kotlin offers cleaner, easier to understand code without all 
>> >> the verbosity that Java forces. 
>> >> 
>> >>> But also when I say java am referring to the JVM technology as well, so 
>> >>> add in all of the JVM languages and it’s even more lopsided. 
>> >> 
>> >> The JVM is not relevant to a discussion about languages. 
>> >> 
>> >> -- 
>> >> 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. 
>> > 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.

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Scott Cotton]

On Sunday, 28 October 2018 15:31:54 UTC+1, Robert Engels wrote:
>
> To clarify, think of the performance improvements in the GC in Go from 1.1 
> to 1.11. Amazing. But you only get these via recompiling which is a 
> barrier. Many java installations frequently get performance improvements 
> with no code changes or recompilation. This is why I’ve been investigating 
> packaging Go binaries with dynamic linkage to the runtime and stdlib. 


In what sense are you or have you been investigating?

The things I see which are blockers to this are
1.  The compiler/runtime are intimately linked, and free to evolve over 
time.  So the runtime API to the compiled code isn't even fixed in a way 
that dynamic-linking would work across versions.
2. The runtime itself manages stacks, so there would need to be some 
assumptions about operating context when it could be linked.  For example, 
if it were linked while the stack is high/deep, then where would the 
runtime put the stack?  where would the runtime system stack be placed?

It's very different than applying a runtime to byte code.

Scott
 

>
>
> Sent from my iPhone 
>
> > On Oct 28, 2018, at 9:23 AM, Robert Engels  > wrote: 
> > 
> > Cool. Not sure why the JVM is not applicable to the discussion as it 
> normally ensures binary compatibility as languages evolve. 
> > 
> > Sent from my iPhone 
> > 
> >>> On Oct 28, 2018, at 9:16 AM, Gerald Henriksen  > wrote: 
> >>> 
> >>> On Sat, 27 Oct 2018 14:33:32 -0500, you wrote: 
> >>> 
> >>> What exactly are you referring to? I wasn’t aware of Android no longer 
> being Java. 
> >> 
> >> At Google I/O 2017 the Android team announced that Kotlin would be 
> >> supported as a first class language along with Java, including full 
> >> support in Android Studio. 
> >> 
> >> While Android will likely never get rid of its Java base, developers 
> >> have been switching to Kotlin due to the advantages it offers over 
> >> Java.  Kotlin offers cleaner, easier to understand code without all 
> >> the verbosity that Java forces. 
> >> 
> >>> But also when I say java am referring to the JVM technology as well, 
> so add in all of the JVM languages and it’s even more lopsided. 
> >> 
> >> The JVM is not relevant to a discussion about languages. 
> >> 
> >> -- 
> >> 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 . 
> > 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.

Re: [go-nuts] Re: Go 2 Proposal Comments

[hay]

I prefer Go's compiled version over JIT of Java/.Net. I've faced the same 
problem with Microsoft's 'dot net.' I asked this with Java and .Net but 
they didn't listen then, and now Microsoft is adopting same with '.Net 
Core' after Go. 

Anyhow when Go came, finally there was another language that I could use 
instead of C/C++, and I appreciate Go developers for this :)

If anyone wants Go VM with JIT, it is open source and probably there will 
be project catering to this. But I like Go the way it is.

The difference with Microsoft is their IDE (Visual Studio) and .Net is 
their cash cow and they are putting lot of development resources into it; 
but Go I believe is not making Google much money. Although Go has the 
potential to turn into very profitable programming language, platform, and 
development tool for Google in my opinion. 

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Michael Jones]

To ground this last comment, every Java execution is a recompile in the
sense that the JVM holds all the magic and applys it to a Java “binary”
before and/or during execution.

The “write once run anywhere slogan” is at best a statement of “you code
once and we’ll localize and concreteize for you at runtime.”

This is little different in basic meaning than saying “run this source code
zip of go code through the ‘go run’ VM and your code will run anywhere.”

No, that’s not the Go intent, but it is correct as a thought experiment to
show why Go-style internal implementation changes to support later GC
changes are possible for interpreter languages, VM languages, and the
“compiled” languages. They are all compiled languages, either statement by
statement, in advance of distribution, at runtime all at once, or lazily on
demand.

The difference is packaging and marketing.

On Sun, Oct 28, 2018 at 7:31 AM Robert Engels  wrote:

> To clarify, think of the performance improvements in the GC in Go from 1.1
> to 1.11. Amazing. But you only get these via recompiling which is a
> barrier. Many java installations frequently get performance improvements
> with no code changes or recompilation. This is why I’ve been investigating
> packaging Go binaries with dynamic linkage to the runtime and stdlib.
>
> Sent from my iPhone
>
> > On Oct 28, 2018, at 9:23 AM, Robert Engels 
> wrote:
> >
> > Cool. Not sure why the JVM is not applicable to the discussion as it
> normally ensures binary compatibility as languages evolve.
> >
> > Sent from my iPhone
> >
> >>> On Oct 28, 2018, at 9:16 AM, Gerald Henriksen 
> wrote:
> >>>
> >>> On Sat, 27 Oct 2018 14:33:32 -0500, you wrote:
> >>>
> >>> What exactly are you referring to? I wasn’t aware of Android no longer
> being Java.
> >>
> >> At Google I/O 2017 the Android team announced that Kotlin would be
> >> supported as a first class language along with Java, including full
> >> support in Android Studio.
> >>
> >> While Android will likely never get rid of its Java base, developers
> >> have been switching to Kotlin due to the advantages it offers over
> >> Java.  Kotlin offers cleaner, easier to understand code without all
> >> the verbosity that Java forces.
> >>
> >>> But also when I say java am referring to the JVM technology as well,
> so add in all of the JVM languages and it’s even more lopsided.
> >>
> >> The JVM is not relevant to a discussion about languages.
> >>
> >> --
> >> 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.
>
> --
> 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 *

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Robert Engels]

To clarify, think of the performance improvements in the GC in Go from 1.1 to 
1.11. Amazing. But you only get these via recompiling which is a barrier. Many 
java installations frequently get performance improvements with no code changes 
or recompilation. This is why I’ve been investigating packaging Go binaries 
with dynamic linkage to the runtime and stdlib. 

Sent from my iPhone

> On Oct 28, 2018, at 9:23 AM, Robert Engels  wrote:
> 
> Cool. Not sure why the JVM is not applicable to the discussion as it normally 
> ensures binary compatibility as languages evolve. 
> 
> Sent from my iPhone
> 
>>> On Oct 28, 2018, at 9:16 AM, Gerald Henriksen  wrote:
>>> 
>>> On Sat, 27 Oct 2018 14:33:32 -0500, you wrote:
>>> 
>>> What exactly are you referring to? I wasn’t aware of Android no longer 
>>> being Java.
>> 
>> At Google I/O 2017 the Android team announced that Kotlin would be
>> supported as a first class language along with Java, including full
>> support in Android Studio.
>> 
>> While Android will likely never get rid of its Java base, developers
>> have been switching to Kotlin due to the advantages it offers over
>> Java.  Kotlin offers cleaner, easier to understand code without all
>> the verbosity that Java forces.
>> 
>>> But also when I say java am referring to the JVM technology as well, so add 
>>> in all of the JVM languages and it’s even more lopsided. 
>> 
>> The JVM is not relevant to a discussion about languages.
>> 
>> -- 
>> 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.

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Robert Engels]

Cool. Not sure why the JVM is not applicable to the discussion as it normally 
ensures binary compatibility as languages evolve. 

Sent from my iPhone

> On Oct 28, 2018, at 9:16 AM, Gerald Henriksen  wrote:
> 
>> On Sat, 27 Oct 2018 14:33:32 -0500, you wrote:
>> 
>> What exactly are you referring to? I wasn’t aware of Android no longer being 
>> Java.
> 
> At Google I/O 2017 the Android team announced that Kotlin would be
> supported as a first class language along with Java, including full
> support in Android Studio.
> 
> While Android will likely never get rid of its Java base, developers
> have been switching to Kotlin due to the advantages it offers over
> Java.  Kotlin offers cleaner, easier to understand code without all
> the verbosity that Java forces.
> 
>> But also when I say java am referring to the JVM technology as well, so add 
>> in all of the JVM languages and it’s even more lopsided. 
> 
> The JVM is not relevant to a discussion about languages.
> 
> -- 
> 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.

Re: [go-nuts] Re: Go 2 Proposal Comments

[Gerald Henriksen]

On Sat, 27 Oct 2018 14:33:32 -0500, you wrote:

>What exactly are you referring to? I wasn’t aware of Android no longer being 
>Java.

At Google I/O 2017 the Android team announced that Kotlin would be
supported as a first class language along with Java, including full
support in Android Studio.

While Android will likely never get rid of its Java base, developers
have been switching to Kotlin due to the advantages it offers over
Java.  Kotlin offers cleaner, easier to understand code without all
the verbosity that Java forces.

> But also when I say java am referring to the JVM technology as well, so add 
> in all of the JVM languages and it’s even more lopsided. 

The JVM is not relevant to a discussion about languages.

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Robert Engels]

I never made any claims about anyone else. I only presented my opinion that 
backwards compatibility is a requirement for success. 

WORA was not a huge factor in Java’s initial success IMO. There was only a 
single dominant OS and all others combined made up a tiny fraction of the 
market. Linux was starting to get some traction and visionaries could see the 
value in WORA but it certainly wasn’t mainstream. If anything WORA helped Sun 
not ISVs. If a new app was written in Java it had a much better chance of being 
available for Solaris which improved Suns position. 

You are completely correct about the compatibility guide. Funny though, in 20 
years of Java I had never read one. I read the 4 and 5 and 6 ones and the 
number of breaking changes is insignificant. With Java 8 as expected, things 
have started to change. Maybe my aversion to radical change in Go is based on 
my position that things have gone off the rails with Java. Gosling knew what he 
was doing when he created it, and now marketing and lesser minds or different 
interests are controlling it, leading to problems. It feels that the same is 
starting to happen in Go... where niche needs start controlling the process. 

The difficult life was due more to continual API changes, not language changes. 

The comment that you failed to address is the OS/services lifespan and tools 
like Linux. Again, still C89. This is the sweet spot for Go IMO so the 
backwards compatibility is more important. 

Next thing Gophers will be crying for is lambda syntax... just wait. 

> On Oct 28, 2018, at 6:55 AM, Henry  wrote:
> 
> 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 binar

Re: [go-nuts] Re: Go 2 Proposal Comments

[Henry]

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 
> 
> )
>
> 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 > 
> 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 
> merit

Re: [go-nuts] Re: Go 2 Proposal Comments

[robert engels]

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 
)

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  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 > 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 receiv

Re: [go-nuts] Re: Go 2 Proposal Comments

[Henry]

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[robert engels]

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  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+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.

[go-nuts] Re: Go 2 Proposal Comments

[hay]

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Robert Engels]

I think you might be confusing my remarks with someone else. I am against 
generics in Go. 

Also, the Java + Android was in reference to installed applications. 

Since very few desktop applications are developed today, you typically need to 
look at back end. Java still dominates here. You could make the claim it is 
C/C++ since most browsers are written in that which means lots of installed 
base. 

If you talk unique applications I don’t think there’s a contest. 

The 99.999 was an exaggeration I thought that was obvious. Still I had linked 
to a academic paper prior that concluded the overwhelming majority in use cases 
were in collections. Don’t have access right now. 

Anyway, I don’t want Go to mess up with generics either, so we’re on the same 
page :)

Sent from my iPhone

> On Oct 27, 2018, at 3:17 PM, Pat Farrell  wrote:
> 
> 
>> On Friday, October 26, 2018 at 11:32:10 PM UTC-4, Robert Engels wrote:
>> First, there is simply no debate, Java += Android,  and you have the most 
>> successful language/platform ever. NO debate.
> 
> Er, I can argue that VisualBasic + Windows is the most successfull but I have 
> no dog in that hunt. or C# and Windows
> The topic was Java's claim for write-once, run-everywhere. Debate tip: don't 
> use one OS, such as Android, to prove "everywhere"
> It kinda ignores wide-spread platforms such as OS-X, Windows, Linux, iOS, and 
> then there are niche platforms like BSD. Everywhere includes all the majors 
> and all the niche.
> 
>> Arguing against Java in terms of “generics are done poorly”, and citing a 
>> third-party FAQ is absurd. The “core" Java tutorial on generics is a 3-4 
>> pages, and almost every Java developer never goes beyond that. 99.% of 
>> Java generic use cases are self explanatory or explained in a matter of 
>> minutes to anyone with any development experience.
> 
> 
> Got proof, citations for your 99.% claim? I bet not.
> If you look at forums such as JavaRanch, you will see lots of questions about 
> Java's generics, and lots of references to the third party FAQ.
> 
> My point is that Java generics were hacked onto the language with an attempt 
> to keep backward compatibility. They are a mess. I won't bother to list why. 
> Go is nice and clean, and I don't think hacking generics into GO using 
> backwards compatibility as the holy grail is a good idea.  Its all IMHO.
> 
> You have not convinced me, and I doubt I can convince you. So let it drop.
> 
> I sure hope that GO doesn't botch it like Java did.
> -- 
> 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.

Re: [go-nuts] Re: Go 2 Proposal Comments

[Pat Farrell]

On Friday, October 26, 2018 at 11:32:10 PM UTC-4, Robert Engels wrote:
>
> First, there is simply no debate, Java += Android,  and you have the most 
> successful language/platform ever. NO debate.
>

Er, I can argue that VisualBasic + Windows is the most successfull but I 
have no dog in that hunt. or C# and Windows
The topic was Java's claim for write-once, run-everywhere. Debate tip: 
don't use one OS, such as Android, to prove "everywhere"
It kinda ignores wide-spread platforms such as OS-X, Windows, Linux, iOS, 
and then there are niche platforms like BSD. Everywhere includes all the 
majors and all the niche.

Arguing against Java in terms of “generics are done poorly”, and citing a 
> third-party FAQ is absurd. The “core" Java tutorial on generics is a 3-4 
> pages, and almost every Java developer never goes beyond that. 99.% of 
> Java generic use cases are self explanatory or explained in a matter of 
> minutes to anyone with any development experience.
>


Got proof, citations for your 99.% claim? I bet not.
If you look at forums such as JavaRanch, you will see lots of questions 
about Java's generics, and lots of references to the third party FAQ.

My point is that Java generics were hacked onto the language with an 
attempt to keep backward compatibility. They are a mess. I won't bother to 
list why. Go is nice and clean, and I don't think hacking generics into GO 
using backwards compatibility as the holy grail is a good idea.  Its all 
IMHO.

You have not convinced me, and I doubt I can convince you. So let it drop.

I sure hope that GO doesn't botch it like Java did.

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[Robert Engels]

What exactly are you referring to? I wasn’t aware of Android no longer being 
Java. But also when I say java am referring to the JVM technology as well, so 
add in all of the JVM languages and it’s even more lopsided. 

Sent from my iPhone

> On Oct 27, 2018, at 9:31 AM, Gerald Henriksen  wrote:
> 
>> On Fri, 26 Oct 2018 22:31:46 -0500, you wrote:
>> 
>> First, there is simply no debate, Java += Android,  and you have the most 
>> successful language/platform ever. NO debate.
> 
> Which explains why, as soon as Google gave them the choice, developers
> began the stampede away from Java to Kotlin.
> 
> Java may be the "most" successful thanks to Android, but that isn't by
> choice and the issues with Java are such that now that there is an
> officially supported alternative it is being dropped as quickly as it
> can.
> 
> -- 
> 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.

Re: [go-nuts] Re: Go 2 Proposal Comments

[Gerald Henriksen]

On Fri, 26 Oct 2018 22:31:46 -0500, you wrote:

>First, there is simply no debate, Java += Android,  and you have the most 
>successful language/platform ever. NO debate.

Which explains why, as soon as Google gave them the choice, developers
began the stampede away from Java to Kotlin.

Java may be the "most" successful thanks to Android, but that isn't by
choice and the issues with Java are such that now that there is an
officially supported alternative it is being dropped as quickly as it
can.

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[robert engels]

That is a different argument entirely.

That you have a team of competent Go developers that are productive in a few 
weeks is a point against generics in Go at all (which is where I am now).

And that was my original point, is that outside of type-safe containers, MOST 
generic code is not needed, since in these cases a specialized type-safe data 
structure will almost certainly be easier to use and test for the upper layers, 
and/or understanding the generic code (or contracts, et al), and is probably 
not worth the effort.

As for the tutorial, maybe I wasn’t clear, but I was trying to show that the 
core is understandable in a few pages, and yes, the edge cases are more 
involved, but almost never does anyone in common code encounter these, and if 
they are not writing common code, they probably have the 
experience/education/intelligence to understand the edge cases easily.

As a bad anecdote, you can peruse StackOverflow, and very rarely are there any 
“how to use Java generics”. The only constant questions are “difference between 
? extends and ? super” and these are not typical use cases.

I think think if people started taking the position that Go is basically C with 
managed memory and no pointers and that is all, Go and the world would end up 
in a better place. Stop trying to make Go something that it isn’t. Square pegs, 
round holes, yada yada yada...





> On Oct 26, 2018, at 11:27 PM, Burak Serdar  wrote:
> 
> On Fri, Oct 26, 2018 at 9:32 PM robert engels  > wrote:
>> 
>> OK, you got me, I’m sucked in - it was a nice balance of yes, BUT no.
>> 
>> First, there is simply no debate, Java += Android,  and you have the most 
>> successful language/platform ever. NO debate.
>> 
>> Arguing against Java’s write-once, run anywhere implementation is a bad 
>> position to take. Yes, if you write a “swing” app, it doesn’t run on Android 
>> (at least not easily), but that is not what the promise of WORA. Any system 
>> that has an “exec command” cannot make that guarantee.  In the “real world” 
>> the promise was delivered on - at least in comparison to any competing 
>> technology. C may be the "most portable” language ever, but I can write GUI 
>> applications in C that have zero chance of running on multiple OSes. The 
>> position is simply invalid.
>> 
>> Arguing against Java in terms of “generics are done poorly”, and citing a 
>> third-party FAQ is absurd. The “core" Java tutorial on generics is a 3-4 
>> pages, and almost every Java developer never goes beyond that. 99.% of 
>> Java generic use cases are self explanatory or explained in a matter of 
>> minutes to anyone with any development experience.
> 
> You seem to agree that Java generics work only "most of the time".
> 
> If you limit yourself to existing collections and stay away from
> arrays at all costs, this is almost true. However, if you're writing
> code that does more than moving data from here to there, you get into
> some edge cases that simply require you to redesign your code to make
> generics work.
> 
> The simplest example I can think of is the fact that new T() won't work.
> 
> Also, the generics tutorial is not really that short:
> https://docs.oracle.com/javase/tutorial/java/generics/index.html 
> 
> 
> Just to clarify, I have too much code written in Java, and I like the
> language. I agree with your comments about WORA. However, I also
> witnessed that a team of developers with no previous Go exposure
> became competent Go developers in just a few weeks, and now writing
> rest apis calling databases at the backend. Most Java developers, on
> the other hand, simply use generics in the context of type-safe
> containers and avoid writing generic code altogether. Java generics
> work for most because of avoidance, not because of ease or utility.
> 
> 
>> 
>> Claiming students have a problem is akin to saying, “my child was great at 
>> finger paints, but is having a real hard time with differential equations. 
>> Differential equations must be broken”.
>> 
>> Are there rare edge cases in Java generics, yes. Do they come into play in 
>> any sort of real-world frequency, no.
>> 
>> The statement, "Happily, Go doesn't have sub-typing in the first place”, 
>> shows the bias. I don’t think Go needs sub-typing either - but I wouldn’t 
>> use Go in many places I would use Java where sub-typing is a huge benefit. 
>> If you wish to debate the value of OO, please start with someone other than 
>> me, because I will just say, I’ve done it a lot of ways, and good OO where 
>> it applies is better than any of the alternatives. Others may have more 
>> nuanced opinions.
>> 
>> And not to pick, but "type erasure makes runtime checks not work”, is 
>> blatantly false. I hope you meant to say “compile time checks”, but still, 
>> in the real-world, it is not an issue.
>> 
>> I think this might be an ivory tower issue. It doesn’t seem pure

Re: [go-nuts] Re: Go 2 Proposal Comments

[Burak Serdar]

On Fri, Oct 26, 2018 at 9:32 PM robert engels  wrote:
>
> OK, you got me, I’m sucked in - it was a nice balance of yes, BUT no.
>
> First, there is simply no debate, Java += Android,  and you have the most 
> successful language/platform ever. NO debate.
>
> Arguing against Java’s write-once, run anywhere implementation is a bad 
> position to take. Yes, if you write a “swing” app, it doesn’t run on Android 
> (at least not easily), but that is not what the promise of WORA. Any system 
> that has an “exec command” cannot make that guarantee.  In the “real world” 
> the promise was delivered on - at least in comparison to any competing 
> technology. C may be the "most portable” language ever, but I can write GUI 
> applications in C that have zero chance of running on multiple OSes. The 
> position is simply invalid.
>
> Arguing against Java in terms of “generics are done poorly”, and citing a 
> third-party FAQ is absurd. The “core" Java tutorial on generics is a 3-4 
> pages, and almost every Java developer never goes beyond that. 99.% of 
> Java generic use cases are self explanatory or explained in a matter of 
> minutes to anyone with any development experience.

You seem to agree that Java generics work only "most of the time".

If you limit yourself to existing collections and stay away from
arrays at all costs, this is almost true. However, if you're writing
code that does more than moving data from here to there, you get into
some edge cases that simply require you to redesign your code to make
generics work.

The simplest example I can think of is the fact that new T() won't work.

Also, the generics tutorial is not really that short:
https://docs.oracle.com/javase/tutorial/java/generics/index.html

Just to clarify, I have too much code written in Java, and I like the
language. I agree with your comments about WORA. However, I also
witnessed that a team of developers with no previous Go exposure
became competent Go developers in just a few weeks, and now writing
rest apis calling databases at the backend. Most Java developers, on
the other hand, simply use generics in the context of type-safe
containers and avoid writing generic code altogether. Java generics
work for most because of avoidance, not because of ease or utility.


>
> Claiming students have a problem is akin to saying, “my child was great at 
> finger paints, but is having a real hard time with differential equations. 
> Differential equations must be broken”.
>
> Are there rare edge cases in Java generics, yes. Do they come into play in 
> any sort of real-world frequency, no.
>
> The statement, "Happily, Go doesn't have sub-typing in the first place”, 
> shows the bias. I don’t think Go needs sub-typing either - but I wouldn’t use 
> Go in many places I would use Java where sub-typing is a huge benefit. If you 
> wish to debate the value of OO, please start with someone other than me, 
> because I will just say, I’ve done it a lot of ways, and good OO where it 
> applies is better than any of the alternatives. Others may have more nuanced 
> opinions.
>
> And not to pick, but "type erasure makes runtime checks not work”, is 
> blatantly false. I hope you meant to say “compile time checks”, but still, in 
> the real-world, it is not an issue.
>
> I think this might be an ivory tower issue. It doesn’t seem pure to some, so 
> it must be bad.
>
> I’ll end with an anecdote from the construction industry.
>
> When laying a deck, you can try to be very accurate and cut all of the boards 
> to the same length, or you install them, and use a straight edge to cut off 
> the ends to exact same length. Real world vs. academia. No experienced 
> carpenter would do it the first way.
>
>
>
>
>
> On Oct 26, 2018, at 9:20 PM, Ian Denhardt  wrote:
>
> Quoting Pat Farrell (2018-10-26 21:30:47)
>
>   This leads to my second issue with the OP's ideas. I strongly believe
>   that Java has been damaged by its attempt to deliver backward
>   compatability. While others have brought up the potential issues with
>   keywords, a much more telling disaster was Java's implementation of
>   generics. It was done in a language compatable way, but there result
>   was design choices and restrictions that make it nearly impossible to
>   use Java generics "properly". Lest you think I exaggerate, look at
>   Exhibit 1, the FAQ on how to actually use it is huge. It has hundreds
>   of edge cases. See
>   FAQ.� http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
>   If the implementation had decided to not require backwards
>   compatibility, they might have been able to design generics such that
>   there is no need for thousands of special case rules that are
>   Frequently Asked.
>
>
> Definitely worth nothing: there *pages* in that FAQ that could have been
> cut if they'd just removed covariant array subtyping, to be consistent
> with the rules for generics and (more importantly) actually sound.
>
> For anyone who doesn't know what I'm talking ab

Re: [go-nuts] Re: Go 2 Proposal Comments

[Ian Denhardt]

Quoting robert engels (2018-10-26 23:31:46)
>OK, you got me, I'm sucked in - it was a nice balance of yes, BUT no.
>
>First, there is simply no debate, Java += Android,  and you have the
>most successful language/platform ever. NO debate.
>Arguing against Java's write-once, run anywhere implementation is a bad
>position to take. Yes, if you write a "swing" app, it doesn't run on
>Android (at least not easily), but that is not what the promise of
>WORA. Any system that has an "exec command" cannot make that guarantee.
> In the "real world" the promise was delivered on - at least in
>comparison to any competing technology. C may be the "most portable"
>language ever, but I can write GUI applications in C that have zero
>chance of running on multiple OSes. The position is simply invalid.
>Arguing against Java in terms of "generics are done poorly",

I'll leave you and Pat to debate this; I don't care all that much.

> and citing a third-party FAQ is absurd.

This is a fair complaint. The linked FAQ seems rather verbose for its content.

> The "core" Java tutorial on generics is a 3-4 pages,

Which tutorial are you talking about? The tutorial on Orcale's website
is decidedly longer than that:

https://docs.oracle.com/javase/tutorial/java/generics/index.html

>Claiming students have a problem is akin to saying, "my child was great
>at finger paints, but is having a real hard time with differential
>equations. Differential equations must be broken".
>Are there rare edge cases in Java generics, yes. Do they come into play
>in any sort of real-world frequency, no.

The problem was not "students have a hard time understanding the
concept" so much as "students come to me to ask for help debugging code
that is throwing this weird specialized exception that they've never
heard of. It's something that should always have been a compile time
error, and *not* fixing it makes the language more complex. (It also
hurts perf to do the runtime check).

NullPointerException is pretty easy to understand too -- that doesn't
make it not a source of bugs.

>The statement, "Happily, Go doesn't have sub-typing in the first
>place", shows the bias. I don't think Go needs sub-typing either - but
>I wouldn't use Go in many places I would use Java where sub-typing is a
>huge benefit. If you wish to debate the value of OO, please start with
>someone other than me, because I will just say, I've done it a lot of
>ways, and good OO where it applies is better than any of the
>alternatives. Others may have more nuanced opinions.

This wasn't meant to be a criticism of subtyping; I was just making the point
that we have an easier problem to deal with, because we don't have to
worry about interactions between the two.

>And not to pick, but "type erasure makes runtime checks not work", is
>blatantly false. I hope you meant to say "compile time checks", but
>still, in the real-world, it is not an issue.

This was in reference to the fact that in Java you can't e.g:

* Have arrays of a parametrized type (e.g. Foo[]) -- the runtime
  check that throws the ArrayStoreException can't work without having
  the type information available at runtime.
* Have exceptions with type parameters -- the dispatching of exceptions
  is on the type, so this doesn't work if you erase the types at compile
  time.

IIRC there were a few other examples in there.

>I think this might be an ivory tower issue. It doesn't seem pure to
>some, so it must be bad.

This is some combination of ad hominem and straw man.

>I'll end with an anecdote from the construction industry.
>When laying a deck, you can try to be very accurate and cut all of the
>boards to the same length, or you install them, and use a straight edge
>to cut off the ends to exact same length. Real world vs. academia. No
>experienced carpenter would do it the first way.

..and yet you seem to be the one advocating never fixing things once
they're in the field?

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

Re: [go-nuts] Re: Go 2 Proposal Comments

[robert engels]

OK, you got me, I’m sucked in - it was a nice balance of yes, BUT no.

First, there is simply no debate, Java += Android,  and you have the most 
successful language/platform ever. NO debate.

Arguing against Java’s write-once, run anywhere implementation is a bad 
position to take. Yes, if you write a “swing” app, it doesn’t run on Android 
(at least not easily), but that is not what the promise of WORA. Any system 
that has an “exec command” cannot make that guarantee.  In the “real world” the 
promise was delivered on - at least in comparison to any competing technology. 
C may be the "most portable” language ever, but I can write GUI applications in 
C that have zero chance of running on multiple OSes. The position is simply 
invalid.

Arguing against Java in terms of “generics are done poorly”, and citing a 
third-party FAQ is absurd. The “core" Java tutorial on generics is a 3-4 pages, 
and almost every Java developer never goes beyond that. 99.% of Java 
generic use cases are self explanatory or explained in a matter of minutes to 
anyone with any development experience.

Claiming students have a problem is akin to saying, “my child was great at 
finger paints, but is having a real hard time with differential equations. 
Differential equations must be broken”.

Are there rare edge cases in Java generics, yes. Do they come into play in any 
sort of real-world frequency, no.

The statement, "Happily, Go doesn't have sub-typing in the first place”, shows 
the bias. I don’t think Go needs sub-typing either - but I wouldn’t use Go in 
many places I would use Java where sub-typing is a huge benefit. If you wish to 
debate the value of OO, please start with someone other than me, because I will 
just say, I’ve done it a lot of ways, and good OO where it applies is better 
than any of the alternatives. Others may have more nuanced opinions.

And not to pick, but "type erasure makes runtime checks not work”, is blatantly 
false. I hope you meant to say “compile time checks”, but still, in the 
real-world, it is not an issue.

I think this might be an ivory tower issue. It doesn’t seem pure to some, so it 
must be bad.

I’ll end with an anecdote from the construction industry.

When laying a deck, you can try to be very accurate and cut all of the boards 
to the same length, or you install them, and use a straight edge to cut off the 
ends to exact same length. Real world vs. academia. No experienced carpenter 
would do it the first way.





> On Oct 26, 2018, at 9:20 PM, Ian Denhardt  wrote:
> 
> Quoting Pat Farrell (2018-10-26 21:30:47)
> 
>>   This leads to my second issue with the OP's ideas. I strongly believe
>>   that Java has been damaged by its attempt to deliver backward
>>   compatability. While others have brought up the potential issues with
>>   keywords, a much more telling disaster was Java's implementation of
>>   generics. It was done in a language compatable way, but there result
>>   was design choices and restrictions that make it nearly impossible to
>>   use Java generics "properly". Lest you think I exaggerate, look at
>>   Exhibit 1, the FAQ on how to actually use it is huge. It has hundreds
>>   of edge cases. See
>>   FAQ.� http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
>>   If the implementation had decided to not require backwards
>>   compatibility, they might have been able to design generics such that
>>   there is no need for thousands of special case rules that are
>>   Frequently Asked.
> 
> Definitely worth nothing: there *pages* in that FAQ that could have been
> cut if they'd just removed covariant array subtyping, to be consistent
> with the rules for generics and (more importantly) actually sound.
> 
> For anyone who doesn't know what I'm talking about:
> 
>class Main {
>public void main(String[] args) }
>String[] strArray = new String[4];
> 
>// Arrays are references, so this points to the same
>// memory:
>Object[] objArray = strArray;
> 
>// Whoops, now there's an integer in your array of
>// strings!
>objArray[0] = new Integer(80);
>}
>}
> 
> This type-checks. It throws an ArrayStoreException at runtime. I do not
> miss explaining ArrayStoreException to students.
> 
> It also seems like 25% of the FAQ amounts to "type erasure makes runtime
> checks not work."
> 
> I don't know of any mistake in Go 1 that's quite as egregious while
> being and quite as easily fixed -- but I agree we should keep our eyes
> out for designs that are becoming far more complicated for the sake of
> backwards compatibility.
> 
> ---
> 
> It is also worth observing that the Java developers were attacking a
> much harder problem in adding generics to Java that we are trying to add
> them to Go -- subtyping and parametricity have very subtle interactions,
> and finding satisfactory ways to mix them has been the subject of a lot
> of type-theory research over the pas

Re: [go-nuts] Re: Go 2 Proposal Comments

[Ian Denhardt]

Quoting Pat Farrell (2018-10-26 21:30:47)

>This leads to my second issue with the OP's ideas. I strongly believe
>that Java has been damaged by its attempt to deliver backward
>compatability. While others have brought up the potential issues with
>keywords, a much more telling disaster was Java's implementation of
>generics. It was done in a language compatable way, but there result
>was design choices and restrictions that make it nearly impossible to
>use Java generics "properly". Lest you think I exaggerate, look at
>Exhibit 1, the FAQ on how to actually use it is huge. It has hundreds
>of edge cases. See
>FAQ.� http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
>If the implementation had decided to not require backwards
>compatibility, they might have been able to design generics such that
>there is no need for thousands of special case rules that are
>Frequently Asked.

Definitely worth nothing: there *pages* in that FAQ that could have been
cut if they'd just removed covariant array subtyping, to be consistent
with the rules for generics and (more importantly) actually sound.

For anyone who doesn't know what I'm talking about:

class Main {
public void main(String[] args) }
String[] strArray = new String[4];

// Arrays are references, so this points to the same
// memory:
Object[] objArray = strArray;

// Whoops, now there's an integer in your array of
// strings!
objArray[0] = new Integer(80);
}
}

This type-checks. It throws an ArrayStoreException at runtime. I do not
miss explaining ArrayStoreException to students.

It also seems like 25% of the FAQ amounts to "type erasure makes runtime
checks not work."

I don't know of any mistake in Go 1 that's quite as egregious while
being and quite as easily fixed -- but I agree we should keep our eyes
out for designs that are becoming far more complicated for the sake of
backwards compatibility.

---

It is also worth observing that the Java developers were attacking a
much harder problem in adding generics to Java that we are trying to add
them to Go -- subtyping and parametricity have very subtle interactions,
and finding satisfactory ways to mix them has been the subject of a lot
of type-theory research over the past few decades. Prior to the past
couple of years, I would have just advised someone designing a new
language to punt on one feature or the other entirely. I might still,
but there have been a few developments of late that that are
encouraging.  Good luck bolting them on to an existing design though.

Happily, Go doesn't have subtyping in the first place.

(there are a few minor things that look like subtyping at first glance,
but I suspect they don't present a problem. It's hard to not be
a bit handwavy here since the language spec is not mathematically
precise wrt the type system).

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

[go-nuts] Re: Go 2 Proposal Comments

[Pat Farrell]

On Wednesday, October 24, 2018 at 11:59:34 AM UTC-4, robert engels wrote:
>
> When Java came along there was a heavy sigh of relief by ISVs that 
> understood write-once, and it will continue to work even as mega company 
> released new OS versions and APIs - the burden was on the JDK/JRE 
> implementation to make sure it worked - not the business. The write-once 
> run “anywhere” was icing on the cake - it opened doors to some markets very 
> cheaply.
> [snip]
> 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...
>

Actually, Java never delivered on the claimed "write once, run anywhere" 
idea. Its simply not feasible unless you restrict the domain to a small 
subset, say command line utilities that take arguments and switched from 
stdin. Smalltalk also claimed this, in a more general, GUI environment. It 
too failed to deliver. Decades before, COBOL was an attempt to do this. the 
"C" in COBOL stands for Common.

IMHO, its impossible to design a language to deliver this run anywhere idea 
when we have no idea how future user interfaces will work. For a couple of 
decades, punched cards were a near universal UI. Then command lines, then 
GUI with mice, pointers and windows. Clearly touch and voice are hot topics 
today. I expect some sort of mental telepathy will be hot in the future.

This leads to my second issue with the OP's ideas. I strongly believe that 
Java has been damaged by its attempt to deliver backward compatability. 
While others have brought up the potential issues with keywords, a much 
more telling disaster was Java's implementation of generics. It was done in 
a language compatable way, but there result was design choices and 
restrictions that make it nearly impossible to use Java generics 
"properly". Lest you think I exaggerate, look at Exhibit 1, the FAQ on how 
to actually use it is huge. It has hundreds of edge cases. See 
FAQ. http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html

If the implementation had decided to not require backwards compatibility, 
they might have been able to design generics such that there is no need for 
thousands of special case rules that are Frequently Asked.

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

[go-nuts] Re: Go 2 Proposal Comments

[Henry]

First, backward compatibility isn't free. The reason why you can still 
compile your "version 1.0" source is because someone gives some thoughts 
about it and puts some extra efforts to make it happen. Backward 
compatibility requires maintenance and adds constraints to future 
development. The more versions you have to support, the more constrained 
you are. I suggest Go should have a reasonable but limited backward 
compatibility.

Second, to me, deprecation is more about code repair. Oracle clearly states 
that the purpose of deprecation is to give developers time to move to the 
new API, and that the deprecated items may be removed from future versions. 
To date, Java hasn't removed any, but Oracle has listed several Java APIs 
to be removed from Java 11.

Third, deprecation happens not because someone has better ways of doing 
things. If someone has better ways of doing things, the new and the old 
APIs can just coexist without needing any deprecation at all. Deprecation 
happens because it is no longer feasible to uphold the existing promises 
using the old API definitions. They may discover new cases where the old 
APIs will produce incorrect result and that it is not possible to repair 
the code without changing the API definitions. Hence, you need people to 
move to the new APIs, because -if they stick to the old APIs- their 
software will be buggy. Thus, it is not always a good idea to allow 
"version 1.0" source to compile.

Whatever decisions Go Team is going to come up with regarding this, I think 
being able to deprecate items and have the compiler flashes some warnings 
whenever these items are used, is a good first step.

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

[go-nuts] Re: Go 2 Proposal Comments

[alanfo]

I didn't know that Ian had written this proposal so thanks for linking to 
it.

Although I haven't had time to read it in detail, I certainly agree with 
the tenor of what he's saying.

I know more about C# than Java and the language team there have always been 
paranoid about not breaking compatibility with previous versions. Although 
lots of new keywords have been introduced since version 1.0, I think I'm 
right in saying that all of them have been 'contextual' and that no 
features have been removed from the language at all!

Given that Go is quite a small language (much smaller than C#), I think 
that removing features from the language is simply not worth the hassle 
unless they are incompatible with new features or are downright dangerous.

Removing the integer to string conversion would break a lot of code (I use 
it quite a lot myself to convert a byte or a rune to a string) and so I'd 
be disappointed if that were done. Sure it can be mildly confusing but 
that's all.

I've also seen it suggested that complex numbers should be removed from the 
language and, whilst they may only be used by a minority of Go programmers, 
they do no harm, work just fine and are in C99 as well. If you moved them 
to the standard library then (unless operator overloading is introduced) 
they'd be far harder to use.

Alan

On Wednesday, October 24, 2018 at 4:59:34 PM UTC+1, robert engels wrote:
>
> I'd like to offer a few comments on Ian's 
> https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md
>
> Since the author admits the least amount of experience with Java, maybe my 
> facts, and many opinions, might offer some insight.
>
> If you head back to the genesis time of Java, there was a dominant tech 
> company that produced the dominant OS and associated development tools. It 
> was a “their way of or the highway” scenario. Almost like clockwork, every 
> OS change was not backwards compatible, at least from the point of, if you 
> wanted to use the new feature in the latest OS, you needed to use new APIs 
> for even the “old stuff”. So development teams and businesses were in this 
> continuous cycle of rewriting the same code for a new API, every few years, 
> all without delivering any new value. Couple this with, you had to be 
> “current” in order to get “support”, and it’s easy to see the strangle hold 
> they had on an industry.
>
> When Java came along there was a heavy sigh of relief by ISVs that 
> understood write-once, and it will continue to work even as mega company 
> released new OS versions and APIs - the burden was on the JDK/JRE 
> implementation to make sure it worked - not the business. The write-once 
> run “anywhere” was icing on the cake - it opened doors to some markets very 
> cheaply.
>
> 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.
>
> 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.