Re: [go-nuts] Generic alternatives: new basic types?

[Ian Denhardt]

Quoting robert engels (2018-09-23 22:50:54)

>I'm often confounded when people discuss Java (at least in comparison
>to Go) as being "heavy". If you read early interviews with Gosling it
>is clear that his design was more about what to leave out, not what to
>include (macros, pre-processor, unsigned arithmetic, etc.) He is a
>brilliant language designer, probably top 10 CS engineers, and I think
>he's worth listening to. I think as people look to "enhance/improve"
>Go, his thoughts and processes might be of value.

I feel like a lot of the complaints about java being "heavy" comes down
to sheer verbosity, some of which is an artifact of the language itself
(no type inference whatsoever), and some of which is the way APIs tend
to be designed; you have lots of identifiers that are like six words
long, everything feels very pedantic a lot of the time. I've found java
to be painful to write without an IDE and autocompletion (like,
*physically* painful -- my bad pinky starts acting up after a while).

None of this is really about the complexity of the language per se. But
much of the discussion in this thread is about what kind of code we'll
see in the wild if we add operator overloading to Go. I think Java is a
good illustration of what that can do to a language. We could delve into
what actually went wrong there, but the point is we need to think things
through.

It seems like Gosling had the right attitude re: simplicity,
but somewhere something fell apart.

I wasn't really around for the days when folks thought Java was this
great simple thing. I started my CS bachelors' in '06; by then Java
already had generics, and they felt very bolted on. They didn't really
work with some of most commonly used types in the language (int,
bool...). Java had this mantra of "everything is an object", but it
rang hollow in light of that. So many aspects of the language seemed
slapped together even then, when I had no basis for comparison. The
subtyping rules for generics are different than the ones for arrays,
because somebody failed to think through the implications of the array
subtyping rules. This program tries to put a string in an array of
integers:

class Main {
public static void main(String[] args) {
Integer[] myInts = new Integer[10];
Object[] myObjs = myInts;
myObjs[0] = "Hello, World!";
}
}

It typechecks! and when you run it, you get:

Exception in thread "main" java.lang.ArrayStoreException: java.lang.String
at Main.main(Main.java:5)

By the time generics got added, that hole in the type system had bit
people enough times that they didn't make the same mistake again. But
it's another dark corner of the language that was frustrating to have to
explain to undergrads years later when I was a TA. Not long after, the
department just started teaching them Python instead.

There are two lessons here, one about type theory and one about design.

The design lesson is that "lets keep things simple," while a great
principle, isn't a substitute for thinking through the details, and
maybe even doing the math.

The good news is that as we look at adding generics to Go, we have a
much easier problem than the designers of Java did. The interactions
between subtyping and parametric polymorphism are notoriously subtle and
complex, and it's not surprising that smart people made the
aforementioned mistake. I think some of the perceived weight of Java's
generics comes from these complex interactions.

But while Java has pervasive subtyping everywhere, Go barely has
subtyping at all, and I have a hunch that the bits that look like
subtyping at first can be formalized in terms of constructs that play
much more nicely with generics.

We can do this right, and have generics in Go be simple and feel like
they belong there.  But the current contract-based design is a
non-solution. It's clear to me that we should be using interfaces
instead, and that need something like operator overloading to make this
work.

I have a sketch of a design for the system in my head; hopefully by the
end of next week I'll have time to write it down and share it.

-- 
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: Help tracking down module dependencies

[thepudds1460]

Hi Justin,

I'm not sure where that gotest.tools is coming from in your particular 
build, and not sure of the root cause of the issue with your http proxy.

However, one thing you could try is a 'replace' directive to try to get 
gotest.tools directly from github. I don't know if that will help your 
particular situation, but you could try adding something like the following 
to the end of your go.mod file:

   replace gotest.tools => github.com/gotestyourself/gotest.tools 
v2.1.0+incompatible

There is some chance that might work around the issue with your http 
proxy.  (And if that starts to complain instead about a failed replace, you 
could also try adding an explicit 'require gotest.tools 
v2.1.0+incompatible' or maybe even 'require gotest.tools v0.0.0' in your 
go.mod file).

--thepudds

On Sunday, September 23, 2018 at 7:59:36 PM UTC-4, Justin Israel wrote:
>
> I'm converting one of my internal projects from glide to a module, after 
> having done two other conversions. But I am hitting a problem that I can't 
> yet solve.
>
> $ GO111MODULE=on go mod tidy -v
>
> Fetching https://gotest.tools?go-get=1
> https fetch failed: Get https://gotest.tools?go-get=1: Forbidden
> go: gotest.tools@v2.1.0+incompatible: unrecognized import path 
> "gotest.tools" (https fetch failed: Get https://gotest.tools?go-get=1: 
> Forbidden)
> go: error loading module requirements
>
> My http proxy won't let me access this, and I can't find usage of it 
> anywhere in my own codebase or in the immediate dependencies (or even my 
> $GOPATH). The mod subcommand isn't being very specific about where this 
> dependency is coming from (even with the graph command). Any pointers would 
> be greatly appreciated. The dependency didn't show up in my glide.lock 
> originally.
>
> My module requirements are:
>
> require (
>   github.com/boltdb/bolt v1.3.1
>   github.com/elazarl/go-bindata-assetfs v1.0.0
>   github.com/gorilla/context v1.1.1
>   github.com/gorilla/mux v1.3.0
>   github.com/pborman/uuid v1.2.0
>   golang.org/x/sys v0.0.0-20170615053224-fb4cac33e319
>   gopkg.in/yaml.v2 v2.2.0
> )
>
>
> Justin
>

-- 
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: Generic alternatives: new basic types?

[Louki Sumirniy]

Choosing a virtual machine target was the wrong decision. All machines have 
a machine in them, why add a virtual one? C already could be compiled on 
every platform, all we got out of it was processing latency and a whole 
extra layer of performance wrinkles that the CPU maker probably already 
fixed.

It's my opinion that if you really think that Go is missing generics you 
just don't know the language well enough nor have used it to solve problems 
others used parametric polymorphism or generics.

The clamour for solutions in the area of error handling and (easier) 
generic programming for go has to do with the wordy constructions required 
to implement data abstraction. To speak of java, it also has the interface, 
and was the biggest champion of the concept for a long time. 

But it's not the feature everyone talks about Java. That's the JVM on every 
processor and the OOP constructions, as everywhere else in programming 
there is no interface. 

But interfaces can solve a lot of these problems and cut down on 
boilerplate, and Go's stdlib already has loads of good though 
unsophisticated examples of interface programming. 

Also in this discussion people are talking about how languages like 
Smalltalk have deep reflection capabilities. Go has 'reflect'. and go has 
interfaces. You can often dodge a lot of use of reflect by using 
interfaces, and *making* types with more metadata is not difficult with Go, 
at all. The error inbuilt interface, for example. It is extremely 
primitive. The way it should be used is that you declare (almost) all types 
as structs and add the attributes you want to them and create interfaces 
that pass and process this data. Then you can use the dot notation to form 
ad hoc constructors, you can create second level names using structs, and 
the thing I have discovered is that once you have a really good set of 
interfaces for things like coding modes, error handling, and so on, when 
you go to actually write the application you can say a lot with quite a 
little.

The downside of this complexity-averse philosophy in go is that even though 
the concept is not that young, I think there is some ways to go before the 
best patterns for interfaces are a settled question. What I love most about 
interfaces is they let my code start to look more like poetry and less like 
math. Maintaining code is very important, and though in some areas Go can 
be quite wordy, the constructions are quite naive and are not difficult to 
edit en masse, the invention of multiple cursors in editors is something Go 
programmers can greatly benefit from. Repetition is bad if it says nothing 
new but at the same time it is easier to unfold what it contains when it is 
in a simple syntax, and easier to generate automatically. Code generators 
are another thing I have started looking at, and I know there is a lot in 
there that would make this type of programming simpler. Turning a struct 
into JSON that can be unmarshalled using reflect does not require reflect, 
a simple string concatenation with some string conversions, which is just a 
bit of array shuffling. The same applies to database serialization. In go 
many times you can gain a lot with the use of some of the wordy stuff, and 
then afterwards you have a neat little black box that you can trust, and 
never have to use that wordy stuff unless you are just building something 
new without a clear map of its parts.

Go puts a lot more power in the hands of the programmer, and doesn't sugar 
over very many things at all. Whether it reads well and is comprehensible 
is more dependent on the programmer than the language, but the benefit is 
being able to ride so close to the metal whenever you need to, and a neat 
construction system to give more flexibility and power.

It's my opinion that when you start to try using interfaces and goroutines 
in new ways you have less bad to say about what is sacrificed for this 
power. I kinda basically wasn't programming much during the time of the 
rise of OOP though it seemed cool when it came out, I was just used to 
BASIC and assembler and my favourite language back then was called "E", 
which, similar to Go, combined a very simple syntax, mashed together some 
syntax patterns from C and Pascal style, but man that compiler flew, it 
felt like nearly as fast as assembler.

Keeping the compilation process simple does mean the programmer must adapt 
their thinking to be more like the machine, but on the flip side, you can 
run through files and make multiple changes easily, with no ambiguity of 
symbols, search and replace and multiple cursors, quite quickly, and 
immediately see the change, plus, more easily write tools that parse it. 
There is many tools already, but the maturity of the field of automated 
programming isn't mature yet, in my view. Instead of wanting go to 
sacrifice that speed and simplicity so you can read your code easier, you 
will just use some declarative focused, maybe mixed embeds of 

Re: [go-nuts] cannot take the address of method()

[Jesse McNelis]

On Mon, Sep 24, 2018 at 5:33 AM, Tamás Király  wrote:
> Hi,
>
> can anyone explain why the following does not work?
> i want to have the return value's address not the method itself.
>
> package main
>
> func main() {
> //first
> addressofstring := ()
> }
>
> func method() string {
> return "value"
> }
>
> https://play.golang.org/p/UbJ7SK0m9w6

You can't take the address of a function call. The Go specification
has further explanation of what you can take the address of.
https://golang.org/ref/spec#Address_operators

The reason you can't take the address of a function call is that it's
ambiguous as to what memory location you're getting the address of. By
not having this as a feature there doesn't need to be a rule to
disambiguate that.

-- 
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] Generic alternatives: new basic types?

[robert engels]

I’m often confounded when people discuss Java (at least in comparison to Go) as 
being “heavy”. If you read early interviews with Gosling it is clear that his 
design was more about what to leave out, not what to include (macros, 
pre-processor, unsigned arithmetic, etc.) He is a brilliant language designer, 
probably top 10 CS engineers, and I think he’s worth listening to. I think as 
people look to “enhance/improve” Go, his thoughts and processes might be of 
value.

Here is a decent early interview 
https://www.javaworld.com/article/2076012/core-java/a-conversation-with-james-gosling.html
 

 and an excerpt:

The role of simplicity

Venners:The opposite of complexity is simplicity. I have often heard you 
describe your philosophy when designing Java in the early days: you didn't put 
something in Java unless five people screamed at you and demanded it. In one 
interview, you told this really good story about moving to a new apartment and 
something about keeping things in boxes.

Gosling:That's actually a general principle for life that works really well. 
When you move to a new apartment, don't unpack. Just sort of move in, and as 
you need things, pull them out of the boxes. After you've been in the apartment 
for a couple of months, take the boxes -- don't even open them -- and just 
leave what's in there and throw them out.

Venners:The 'don't even open them' part is important because it's very hard to 
throw things away once you know what they are.

Gosling: Right, because if you open them, you say, 'oh, I can't part with that.'

Venners:So would you say that simplicity is a general philosophy programmers 
should always have when designing programs?

Gosling:I think in any kind of design, you must drive for simplicity all the 
time. If you don't, complexity will nail you. Dealing with complexity is hard 
enough.

In programming language design, one of the standard problems is that the 
language grows so complex that nobody can understand it. One of the little 
experiments I tried was asking people about the rules for unsigned arithmetic 
in C. It turns out nobody understands how unsigned arithmetic in C works. There 
are a few obvious things that people understand, but many people don't 
understand it.

So one of the most important criteria for judging a design for me is the 
manual. Is the manual out of control, or is it reasonably concise? You can 
write a pretty decent Java manual in less than 100 pages. The current Java 
language spec is pretty thick, but that's because it's probably the most 
detailed language spec ever written. It goes through all of the details. I 
couldn't write the Java language spec.


> On Sep 23, 2018, at 3:34 PM, Michael Jones  wrote:
> 
> You did not offend me. This is a place for earnest ideas and all are welcome.
> 
> Your comment is not yet persuasive, but it might become so. Still thinking. I 
> first heard from James Gosling about Java when Java was Oak. He seemed proud 
> to say, "C++ has objects. Well, I'll show them, I'll make everything 
> objects!" That they did. I've been recalling those days and wondering if that 
> team knew more about language design in some privileged way or was just 
> turning the knob to eleven. Still not sure.
> 
> I am sure that Alan Kay et al had important, fundamental insights in 
> Smalltalk. Variables had named attributes and they could be inspected in code 
> and visually with an inspector. I could ask you about your type, size, 
> length, etc. If i asked an inapplicable question i got a survivable answer, 
> not a panic. I raised this pre-Go1 in Google with the idea of, why are Len() 
> and Cap() not implicit methods on a slice? I like that because it also 
> suggests asking a variable, "hey, what is your minimum expressible value?" in 
> a way that is type agnostic. Being able to as parameter t of generic type T a 
> question like "x := t.MinExpressibleValue()" has a grand flexibility compared 
> to a type switch that then knows about library functions for 
> math.MinFloat64(). There were reasons why not, but in this quest I'm not 
> persuaded against the notion that every common attribute of T should be 
> knowable from t, an instance of that type. In Go this happens with magic 
> compiler generics (len(x), cap(x), ...) that take any and all types and do 
> the right thing. I'm more a fan of no magic and a simple universal notion 
> that applies to every type, built-in or custom.
> 
> In this sense, the Java team's gusto and my deep respect for Smalltalk's "a 
> queryable database of instances" (aka, DOM decades before) align and I do 
> like that path.
> 
> On Sun, Sep 23, 2018 at 9:17 AM Robert Engels  > wrote:
> I take offense to that. I apologized for my statement that was worded more 
> harshly than intended. But if you think that Go is beyond criticism just 
> because of ??? Anything??? Go is a 

[go-nuts] Help tracking down module dependencies

[Justin Israel]

I'm converting one of my internal projects from glide to a module, after
having done two other conversions. But I am hitting a problem that I can't
yet solve.

$ GO111MODULE=on go mod tidy -v

Fetching https://gotest.tools?go-get=1
https fetch failed: Get https://gotest.tools?go-get=1: Forbidden
go: gotest.tools@v2.1.0+incompatible: unrecognized import path
"gotest.tools" (https fetch failed: Get https://gotest.tools?go-get=1:
Forbidden)
go: error loading module requirements

My http proxy won't let me access this, and I can't find usage of it
anywhere in my own codebase or in the immediate dependencies (or even my
$GOPATH). The mod subcommand isn't being very specific about where this
dependency is coming from (even with the graph command). Any pointers would
be greatly appreciated. The dependency didn't show up in my glide.lock
originally.

My module requirements are:

require (
github.com/boltdb/bolt v1.3.1
github.com/elazarl/go-bindata-assetfs v1.0.0
github.com/gorilla/context v1.1.1
github.com/gorilla/mux v1.3.0
github.com/pborman/uuid v1.2.0
golang.org/x/sys v0.0.0-20170615053224-fb4cac33e319
gopkg.in/yaml.v2 v2.2.0
)


Justin

-- 
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] cannot take the address of method()

[Tamás Király]

Hi,

can anyone explain why the following does not work?
i want to have the return value's address not the method itself.

package main

func main() {
//first
addressofstring := ()
}

func method() string {
return "value"
}

https://play.golang.org/p/UbJ7SK0m9w6

regards
Tamás Király

-- 
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: Generic alternatives: new basic types?

[Nhiên Phan]

Hi everybody. I'm a beginner at Golang. Anyone who has the talent to Golang
please let me please

On Mon, Sep 24, 2018 at 1:05 AM Ian Denhardt  wrote:

> Quoting Robert Engels (2018-09-23 13:38:04)
> > I wasn’t suggesting that Go should resemble Java. I was just trying to
> point out that many of the current issues under debate for Go2 have been
> resolved quite well in other languages, and looking to them for direction
> should not be out of bounds just because they are not Go. That’s a little
> short sighted IMO.
>
> Java doesn't allow basic types to be used in generics at all (except for
> arrays, which are magic like Go's slices and maps are today). The issue
> under discussion crops up because we want to be able to talk about both
> MyGenericType(MyCustomType) and MyGenericType(int). The fact that basic
> types are totally separated from objects is a big wart in the language,
> so Java isn't really a great source of ideas re: how to deal with the
> question currently under discussion.
>
> --
> 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: Generic alternatives: new basic types?

[Michael Jones]

You did not offend me. This is a place for earnest ideas and all are
welcome.

Your comment is not yet persuasive, but it might become so. Still thinking.
I first heard from James Gosling about Java when Java was Oak. He seemed
proud to say, "C++ has objects. Well, I'll show them, I'll make *everything*
objects!" That they did. I've been recalling those days and wondering if
that team knew more about language design in some privileged way or was
just turning the knob to eleven. Still not sure.

I am sure that Alan Kay et al had important, fundamental insights in
Smalltalk. Variables had named attributes and they could be inspected in
code and visually with an inspector. I could ask you about your type, size,
length, etc. If i asked an inapplicable question i got a survivable answer,
not a panic. I raised this pre-Go1 in Google with the idea of, why are
Len() and Cap() not implicit methods on a slice? I like that because it
also suggests asking a variable, "hey, what is your minimum expressible
value?" in a way that is type agnostic. Being able to as parameter t of
generic type T a question like "x := t.MinExpressibleValue()" has a grand
flexibility compared to a type switch that then knows about library
functions for math.MinFloat64(). There were reasons why not, but in this
quest I'm not persuaded against the notion that *every common attribute of
T should be knowable from t, an instance of that type*. In Go this happens
with magic compiler generics (len(x), cap(x), ...) that take any and all
types and do the right thing. I'm more a fan of no magic and a simple
universal notion that applies to every type, built-in or custom.

In this sense, the Java team's gusto and my deep respect for Smalltalk's "a
queryable database of instances" (aka, DOM decades before) align and I do
like that path.

On Sun, Sep 23, 2018 at 9:17 AM Robert Engels  wrote:

> I take offense to that. I apologized for my statement that was worded more
> harshly than intended. But if you think that Go is beyond criticism just
> because of ??? Anything??? Go is a GREAT tool for many classes of
> applications, but it is certainly not appropriate for all use cases. Maybe
> with open criticism it could get there, but I don’t think your attitude
> will help it. I am certainly not the first nor the last to highlight many
> deficiencies in Gos design. That’s the great thing about software though,
> it is malleable.
>
> Sent from my iPhone
>
> > On Sep 23, 2018, at 9:01 AM, Lucio De Re  wrote:
> >
> > I take exception to that statement, your notion of "understood
> > languages much better" doesn't parse in light of the fact that you are
> > here, debating the merits of Java in the primary Go forum instead of
> > writing wonderful code using the language  you respect so much.
> >
> > That's either hypocritical or merely absurd in addition to the rather
> > inappropriate, unjustified and offensive ad hominem that accompanies
> > it.
> >
> > Lucio.
> >
> >> On 9/23/18, Robert Engels  wrote:
> >> Issues like these highlight the deficiencies of Go compared to Java. The
> >> Java designers understood languages far better, and from the start
> realized
> >> that identity and reference equality were different concepts. Everyone
> in Go
> >> land are debating these solved issues. Pick and chose what you want to
> >> implement but there doesn’t really need to be a debate on how to do it.
> >>
> >> Sent from my iPhone
> >>
>  On Sep 22, 2018, at 8:52 PM, Ian Denhardt  wrote:
> 
>  On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
> 
>   I think the thing everyone who likes operator overloading like mainly
>   is being able to do infix and postfix syntax, instead of only prefix
>   (function).
> >>>
> >>> My own reason for wanting this is not really about syntax, so much as
> >>> being able to define functions etc. which e.g. check for equality,
> >>> without having to write too versions -- one that uses `==` and one
> >>> that calls some method custom types. The syntax isn't really the point;
> >>> there's an underlying notion of equality that we want to be able to
> talk
> >>> about for more than just built-in types. We could define an interface
> >>> for this:
> >>>
> >>>   // The Equatable interface wraps the basic Equals method.
> >>>   //
> >>>   // x.Equals(y) tests whether x and y are "the same." The predicate
> >>>   // Equals should obey a few common sense rules:
> >>>   //
> >>>   // 1. It should be reflexive: x.Equals(x) should always return true
> >>>   //(for any x).
> >>>   // 2. It should be symmetric: x.Equals(y) should be the same as
> >>>   //y.Equals(x)
> >>>   // 3. It should be transitive: if x.Equals(y) and y.Equals(z), then
> >>>   //x.Equals(z).
> >>>   //
> >>>   // It generally does not make sense for a type to implement
> >>>   // Equatable where the type parameter T is something other than
> >>>   // itself.
> >>>   type Equatable(T) interface {
> >>>   Equals(T) 

Re: [go-nuts] Re: Generic alternatives: new basic types?

[Ian Denhardt]

Quoting Robert Engels (2018-09-23 13:38:04)
> I wasn’t suggesting that Go should resemble Java. I was just trying to point 
> out that many of the current issues under debate for Go2 have been resolved 
> quite well in other languages, and looking to them for direction should not 
> be out of bounds just because they are not Go. That’s a little short sighted 
> IMO.

Java doesn't allow basic types to be used in generics at all (except for
arrays, which are magic like Go's slices and maps are today). The issue
under discussion crops up because we want to be able to talk about both
MyGenericType(MyCustomType) and MyGenericType(int). The fact that basic
types are totally separated from objects is a big wart in the language,
so Java isn't really a great source of ideas re: how to deal with the
question currently under discussion.

-- 
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: Generic alternatives: new basic types?

[Robert Engels]

I wasn’t suggesting that Go should resemble Java. I was just trying to point 
out that many of the current issues under debate for Go2 have been resolved 
quite well in other languages, and looking to them for direction should not be 
out of bounds just because they are not Go. That’s a little short sighted IMO. 

> On Sep 23, 2018, at 12:13 PM, Lucio De Re  wrote:
> 
>> On 9/23/18, Robert Engels  wrote:
>> I take offense to that. I apologized for my statement that was worded more
>> harshly than intended. But if you think that Go is beyond criticism just
>> because of ??? Anything??? Go is a GREAT tool for many classes of
>> applications, but it is certainly not appropriate for all use cases. Maybe
>> with open criticism it could get there, but I don’t think your attitude will
>> help it. I am certainly not the first nor the last to highlight many
>> deficiencies in Gos design. That’s the great thing about software though, it
>> is malleable.
>> 
> I responded harshly, too and that wasn't necessary, so I owe everyone
> an apology.
> 
> But setting Java as the paragon for Go is not going to win anyone to
> your cause, either. Java exists, it is available, it is what it is.
> Why would Go want to resemble it?
> 
> Lucio.

-- 
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: Generic alternatives: new basic types?

[Lucio De Re]

On 9/23/18, Robert Engels  wrote:
> I take offense to that. I apologized for my statement that was worded more
> harshly than intended. But if you think that Go is beyond criticism just
> because of ??? Anything??? Go is a GREAT tool for many classes of
> applications, but it is certainly not appropriate for all use cases. Maybe
> with open criticism it could get there, but I don’t think your attitude will
> help it. I am certainly not the first nor the last to highlight many
> deficiencies in Gos design. That’s the great thing about software though, it
> is malleable.
>
I responded harshly, too and that wasn't necessary, so I owe everyone
an apology.

But setting Java as the paragon for Go is not going to win anyone to
your cause, either. Java exists, it is available, it is what it is.
Why would Go want to resemble it?

Lucio.

-- 
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: Generic alternatives: new basic types?

[Robert Engels]

I take offense to that. I apologized for my statement that was worded more 
harshly than intended. But if you think that Go is beyond criticism just 
because of ??? Anything??? Go is a GREAT tool for many classes of applications, 
but it is certainly not appropriate for all use cases. Maybe with open 
criticism it could get there, but I don’t think your attitude will help it. I 
am certainly not the first nor the last to highlight many deficiencies in Gos 
design. That’s the great thing about software though, it is malleable.  

Sent from my iPhone

> On Sep 23, 2018, at 9:01 AM, Lucio De Re  wrote:
> 
> I take exception to that statement, your notion of "understood
> languages much better" doesn't parse in light of the fact that you are
> here, debating the merits of Java in the primary Go forum instead of
> writing wonderful code using the language  you respect so much.
> 
> That's either hypocritical or merely absurd in addition to the rather
> inappropriate, unjustified and offensive ad hominem that accompanies
> it.
> 
> Lucio.
> 
>> On 9/23/18, Robert Engels  wrote:
>> Issues like these highlight the deficiencies of Go compared to Java. The
>> Java designers understood languages far better, and from the start realized
>> that identity and reference equality were different concepts. Everyone in Go
>> land are debating these solved issues. Pick and chose what you want to
>> implement but there doesn’t really need to be a debate on how to do it.
>> 
>> Sent from my iPhone
>> 
 On Sep 22, 2018, at 8:52 PM, Ian Denhardt  wrote:
 
 On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
 
  I think the thing everyone who likes operator overloading like mainly
  is being able to do infix and postfix syntax, instead of only prefix
  (function).
>>> 
>>> My own reason for wanting this is not really about syntax, so much as
>>> being able to define functions etc. which e.g. check for equality,
>>> without having to write too versions -- one that uses `==` and one
>>> that calls some method custom types. The syntax isn't really the point;
>>> there's an underlying notion of equality that we want to be able to talk
>>> about for more than just built-in types. We could define an interface
>>> for this:
>>> 
>>>   // The Equatable interface wraps the basic Equals method.
>>>   //
>>>   // x.Equals(y) tests whether x and y are "the same." The predicate
>>>   // Equals should obey a few common sense rules:
>>>   //
>>>   // 1. It should be reflexive: x.Equals(x) should always return true
>>>   //(for any x).
>>>   // 2. It should be symmetric: x.Equals(y) should be the same as
>>>   //y.Equals(x)
>>>   // 3. It should be transitive: if x.Equals(y) and y.Equals(z), then
>>>   //x.Equals(z).
>>>   //
>>>   // It generally does not make sense for a type to implement
>>>   // Equatable where the type parameter T is something other than
>>>   // itself.
>>>   type Equatable(T) interface {
>>>   Equals(T) bool
>>>   }
>>> 
>>> What I am suggesting is merely that `==` desugars to a use of this
>>> interface.
>>> 
>>> An important litmus test for any operator we consider for overloading is
>>> whether we can come up with a clearly specified interface for it like
>>> the above. If not, it does not make sense to allow the operator to be
>>> overloaded, since it is not clear what overloaders should do. I believe
>>> this is the source of most of the problems with operator overloading in
>>> other languages.
>>> 
>>> I think if we stick to this things will stay under control; there's
>>> currently nothing stopping folks from defining an instance of
>>> io.Writer that does something utterly in conflict with what is described
>>> in its documentation -- but that hasn't seemed to be a problem in
>>> practice.
>>> 
>>> Quoting Michael Jones (2018-09-22 13:14:21)
  the reason i wrote something like "...operator overloading, but wait,
  don't get excited..." was to bring awareness of a core problem without
  (hopefully) having people bring the burden of experience. i say burden
  because bad experiences can shadow the 'why' that was good with the
  'how' that was bad. let the why foremost to "break these chains, rise
  up, and move beyond" as in Callicles' famous speech.
  the essential meaning of operator overloading and go interfaces and
  Smalltalk messaging is a way to bind code to intent. (in general
 intent
  is named uniquely ("==") for simplicity but that is independent.)
  Generics raise the need a way to say how the standard intentions play
  out for our types. Imagine our gopher attired as a waiter, politely
  asking questions of a custom type:
 
  gopher: Will you want to test for equality, madam?
 
  type: Yes, thank you.
 
  gopher: How would you prefer that test to be done?
 
  type: Hmm... I'll try 'IsEqualWithOddName(a, b *type)" for now.
 
  gopher: very good, madam.

Re: [go-nuts] Re: Generic alternatives: new basic types?

[Lucio De Re]

I take exception to that statement, your notion of "understood
languages much better" doesn't parse in light of the fact that you are
here, debating the merits of Java in the primary Go forum instead of
writing wonderful code using the language  you respect so much.

That's either hypocritical or merely absurd in addition to the rather
inappropriate, unjustified and offensive ad hominem that accompanies
it.

Lucio.

On 9/23/18, Robert Engels  wrote:
> Issues like these highlight the deficiencies of Go compared to Java. The
> Java designers understood languages far better, and from the start realized
> that identity and reference equality were different concepts. Everyone in Go
> land are debating these solved issues. Pick and chose what you want to
> implement but there doesn’t really need to be a debate on how to do it.
>
> Sent from my iPhone
>
>> On Sep 22, 2018, at 8:52 PM, Ian Denhardt  wrote:
>>
>>> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>>>
>>>   I think the thing everyone who likes operator overloading like mainly
>>>   is being able to do infix and postfix syntax, instead of only prefix
>>>   (function).
>>
>> My own reason for wanting this is not really about syntax, so much as
>> being able to define functions etc. which e.g. check for equality,
>> without having to write too versions -- one that uses `==` and one
>> that calls some method custom types. The syntax isn't really the point;
>> there's an underlying notion of equality that we want to be able to talk
>> about for more than just built-in types. We could define an interface
>> for this:
>>
>>// The Equatable interface wraps the basic Equals method.
>>//
>>// x.Equals(y) tests whether x and y are "the same." The predicate
>>// Equals should obey a few common sense rules:
>>//
>>// 1. It should be reflexive: x.Equals(x) should always return true
>>//(for any x).
>>// 2. It should be symmetric: x.Equals(y) should be the same as
>>//y.Equals(x)
>>// 3. It should be transitive: if x.Equals(y) and y.Equals(z), then
>>//x.Equals(z).
>>//
>>// It generally does not make sense for a type to implement
>>// Equatable where the type parameter T is something other than
>>// itself.
>>type Equatable(T) interface {
>>Equals(T) bool
>>}
>>
>> What I am suggesting is merely that `==` desugars to a use of this
>> interface.
>>
>> An important litmus test for any operator we consider for overloading is
>> whether we can come up with a clearly specified interface for it like
>> the above. If not, it does not make sense to allow the operator to be
>> overloaded, since it is not clear what overloaders should do. I believe
>> this is the source of most of the problems with operator overloading in
>> other languages.
>>
>> I think if we stick to this things will stay under control; there's
>> currently nothing stopping folks from defining an instance of
>> io.Writer that does something utterly in conflict with what is described
>> in its documentation -- but that hasn't seemed to be a problem in
>> practice.
>>
>> Quoting Michael Jones (2018-09-22 13:14:21)
>>>   the reason i wrote something like "...operator overloading, but wait,
>>>   don't get excited..." was to bring awareness of a core problem without
>>>   (hopefully) having people bring the burden of experience. i say burden
>>>   because bad experiences can shadow the 'why' that was good with the
>>>   'how' that was bad. let the why foremost to "break these chains, rise
>>>   up, and move beyond" as in Callicles' famous speech.
>>>   the essential meaning of operator overloading and go interfaces and
>>>   Smalltalk messaging is a way to bind code to intent. (in general
>>> intent
>>>   is named uniquely ("==") for simplicity but that is independent.)
>>>   Generics raise the need a way to say how the standard intentions play
>>>   out for our types. Imagine our gopher attired as a waiter, politely
>>>   asking questions of a custom type:
>>>
>>>   gopher: Will you want to test for equality, madam?
>>>
>>>   type: Yes, thank you.
>>>
>>>   gopher: How would you prefer that test to be done?
>>>
>>>   type: Hmm... I'll try 'IsEqualWithOddName(a, b *type)" for now.
>>>
>>>   gopher: very good, madam.
>>>
>>>   This mutual understanding needs to happen. how is open to discussion.
>>>   go interfaces use standard method names. operator overloading uses
>>>   standard symbols. macro expansion uses arguments. no matter how it
>>>   manifests, the power of generics relies on understanding related
>>> parts.
>>>   we should talk about what kinds of parts deserve awareness.
>>>
>>>   On Sat, Sep 22, 2018 at 8:46 AM Lucio <[1]lucio.d...@gmail.com> wrote:
>>>
>>
   It's good that you brought that up, because another issue I
>> remember
>>>   from C++ V1.0 days, is that operator overloading did not allow for
>>>   changes in operator precedence, an arbitrary sop to some weird
>>>   decisions 

Re: [go-nuts] Re: Generic alternatives: new basic types?

[Robert Engels]

I’m sorry. I did not mean to offend anyone. It came out wrong and I apologize. 

Sent from my iPhone

> On Sep 23, 2018, at 5:01 AM, Louki Sumirniy 
>  wrote:
> 
> The thing that people are concerned about is creating a construct that 
> enables you to write legal but confusing and unclear code. Let's say we steal 
> triple equals ===, and then use it to mean some kind of special assignment 
> operation. Or we make = become an addition operator infix for a 
> string-related type.
> 
> Interfaces don't cover the case of operator precedence, interfaces are all 
> verb subject object. Operator precedence is a syntactic layer that does not 
> have at least an easily inferred type and require deeper analysis of the AST 
> before you can get the types right. The bigger reason to not allow constructs 
> like this in Go is because one of its main advantages is simple parsing, 
> which means tooling and nearly interactive speed testing. Go even can use 
> spaces (or not) to override precedence. Either the implementation forces each 
> operator symbol to be of only one precedence relation to others, or you are 
> leaving out milk and cookies for the kinds of programmers that make people 
> want to invent a language like Go.
> 
> The case for equality operators is a pretty good one though. The reason why 
> an infix operator is preferable for equality operations is because both 
> operands are being tested for equality. It doesn't matter which order, unlike 
> verb subject object of function notation. + is already used for string 
> concatenation, logically it could and probably should also apply to any type 
> of sliceable array type.
> 
> I am against a wide open operator override system, most especially one that 
> allows the disruption of the conventional order of precedence for the 
> operator. But a small set that is declared like an interface and only covers 
> a very small subset, the most useful ones, like +, ++, --, !=, ==, <, >.
> 
> A central pillar of the design process of Go is all about avoiding complexity 
> where flexibility can substitute and not add an excessive and questionable 
> cost for an operation that is not that commonly used especially when it 
> decreases the approachability of code. Overloaded equality, increment and 
> comparision operators would not increase the ambiguity for either humans or 
> the source code. If you can assert the type of an operator from only one of 
> its operands this is less parsing than a case where you have to disambiguate 
> both. Type casting should never be implicit, so for a Go version of operator 
> overloading, there would not be conversion involved - a full parse showing 
> differing types on an operator operand would thus be illegal. Unless both 
> operands are both implementors of the same countable interface, for example, 
> and they either use interface{} or a defined interface name as 
> returns/inputs. I think that this is a step further on from just allowing 
> redefinition of (some) operators to bind to new types, and to allow those 
> types to create assignment channels, for example. And this is where the big 
> syntax bugbear appears. Overriding an operator is one thing, but defining two 
> types as being comparable and assignable with each other will pretty quickly 
> grow into a hella boilerplate for a shortcut used 10 times in a 1000 line 
> project, and ever growing compilation times.
> 
> Go is a simple language, and anything that will take away the simplicity, 
> with its benefits in learning, reading and compiling, will and should be 
> rejected as an addition to the language spec. I would argue that a small set 
> of infix operators and maybe some unarys would not create such complexity. 
> Especially if we restrict it to unary post/prefix, addition, subtraction 
> equality and assignment, and don't change the precedence rules. Really, 
> precedence would not be relevant, and there should not be any ambiguity 
> allowed in how an overridden symbol can be used. Precedence really only 
> irritates everyone between add/subtract and multiply, square, and only for 
> countable types. To stop complexity creeping into the parser, also, no change 
> in the rule about casting. No implicit casts. Implicit casts are probably one 
> of the most irritating and pervasive features of C type languages. I always 
> have to double and triple check. Even between some version changes C++ has 
> substantially disrupted the rules about it and I just don't think that 
> implicit casting is a good construct in a language. Implicit typing through 
> inference does not have this problem.
> 
>> On Sunday, 23 September 2018 08:35:15 UTC+2, Robert Engels wrote:
>> Issues like these highlight the deficiencies of Go compared to Java. The 
>> Java designers understood languages far better, and from the start realized 
>> that identity and reference equality were different concepts. Everyone in Go 
>> land are debating these solved issues. Pick and chose what you 

[go-nuts] Re: Serve HTML/CSS/JS as a desktop app?

[Louki Sumirniy]

There is a lotta stuff that can be done with html and css now without 
javascript, but for this kind of application I think that the display side 
(the webkit/blink engine) has to have a websocket to the server backend to 
allow pushing updates to the DOM, at least refreshes. But this is not a 
huge chunk of code required and likely already has implementations. 
Basically just to be able to push new objects into existing ones on 
triggers from ticks or network events would be essential. But a) that could 
be built into a thin layer wrapping a DOM canvas implemented maybe in Go, 
that eliminates the limitation of not being able to use sockets instead of 
websockets, and one simple  command 'replace object X with object Y. 
Whether it is a list of posts or the ongoing update of a price ticker.

If you are wanting it to integrate like Electron, however, that's a little 
different. Go can talk directly to local services, dbus, x, and so on, and 
so I think already there is enough that you can open a window in X that is 
100% webkit DOM canvas that you can, through this service I am proposing, a 
small wrapper around a simple borderless webkit canvas, that speaks via 
socket to the server backend, opening the channel to implement all the 
things that Electron allows like system tray icons and gnome application 
menus and whatnot. The skinny controller service wrapped around the canvas 
would mainly need to be able to send window geometry and compositing 
requests, and webkit itself has the input queue that you could connect to 
goroutines for instant response. I think you can even, with gnome at least, 
even add the decorator/controls natively, or with fallback, to Broadway, 
which also wraps around a HTML/CSS/DOM, so it can coexist if you wanted it 
to. 

I am very interested in this direction of inquiry as I want to develop 
transparent (a la plan 9) application routing such that running a service 
locally, fully remote, or some mix of local and remote components 
cooperating. So you can have an application that will run anywhere there is 
Go, a modicum of support of system calls for network, storage and general 
IO, that can either use one or more 'windows' or be itself a window manager 
and desktop environment complete with interfaces to IO and system level 
configuration (network, display, audio, etc). Something that would allow, 
for example, to ad-hoc join another display from another device (let's say 
we have a desktop with system monitor, a mobile phone, a tablet and a 
laptop all arrayed around us, and they can all either directly run the 
back-end processing or connect to another device to do this. The phone 
could be decoding audio that is playing out of a HDMI connected monitor or 
through a bluetooth on the tablet, the desktop accessing files on the 
mobile and laptop at the same time in a FUSE overlay filesystem, the phone 
sending video to the desktop to encode for a 60hz 4k video stream from 
lossless frames instead of 3gp or avc encoding on the device, and windows 
can be dragged off one device and appear a moment later on another device's 
display, with processing optionally migrating or connecting via the GUI 
protocol (ie, push DOM changes).

It's really hot subject at the moment and I think that with a language like 
Go and the universality and competence of Webkit and Blink soon nobody's 
going to care except for real issues whether it's got a bsd mach, darwin, 
WOW64 or CPM kernel or if webkit is running on bare metal inside kernel 
mode with no enforced MMU fencing by the executive... The way I see it, 
bare metal, static native compiled, and an inbuilt source repository 
system, will win out because it cannot be made any faster, and with a cheap 
to compile, powerful and flexible language like Go in the middle of it. Rip 
out ECMAscript engine from webkit, put a go compile server in its place, 
and your Go can run native in the background, middle or just under the 
surface directly controlling elements of the canvas directly.

I have been studying the field of operating systems and languages for a 
long time and there is a long overdue need to revisit the places Plan9, 
NoKernel, Exokernels, bare metal builds and JiT compilation caching for a 
proper native binary object form for executables and libraries, and sockets 
everywhere! It's coming back, and I think it's just a matter of time before 
'kernel' becomes more connected to firmware binary blobs for coprocessing 
and IO systems, and, really, do we need a pre-emptive executive when we can 
have goroutines instead? All this discussion about how much nicer Java is 
but Java does not have Goroutines. Go has the ingredients inside it already 
for an alternative model for parallel and concurrent processing, imagine 
one process per core that manages all execution via goroutines, and on some 
devices, like video cards, they can run their own kernel and server that 
... well, I know that every hardcore gopher dreams of the 'everything 

Re: [go-nuts] Re: Generic alternatives: new basic types?

[Louki Sumirniy]

The thing that people are concerned about is creating a construct that 
enables you to write legal but confusing and unclear code. Let's say we 
steal triple equals ===, and then use it to mean some kind of special 
assignment operation. Or we make = become an addition operator infix for a 
string-related type.

Interfaces don't cover the case of operator precedence, interfaces are all 
verb subject object. Operator precedence is a syntactic layer that does not 
have at least an easily inferred type and require deeper analysis of the 
AST before you can get the types right. The bigger reason to not allow 
constructs like this in Go is because one of its main advantages is simple 
parsing, which means tooling and nearly interactive speed testing. Go even 
can use spaces (or not) to override precedence. Either the implementation 
forces each operator symbol to be of only one precedence relation to 
others, or you are leaving out milk and cookies for the kinds of 
programmers that make people want to invent a language like Go.

The case for equality operators is a pretty good one though. The reason why 
an infix operator is preferable for equality operations is because both 
operands are being tested for equality. It doesn't matter which order, 
unlike verb subject object of function notation. + is already used for 
string concatenation, logically it could and probably should also apply to 
any type of sliceable array type.

I am against a wide open operator override system, most especially one that 
allows the disruption of the conventional order of precedence for the 
operator. But a small set that is declared like an interface and only 
covers a very small subset, the most useful ones, like +, ++, --, !=, ==, 
<, >.

A central pillar of the design process of Go is all about avoiding 
complexity where flexibility can substitute and not add an excessive and 
questionable cost for an operation that is not that commonly used 
especially when it decreases the approachability of code. Overloaded 
equality, increment and comparision operators would not increase the 
ambiguity for either humans or the source code. If you can assert the type 
of an operator from only one of its operands this is less parsing than a 
case where you have to disambiguate both. Type casting should never be 
implicit, so for a Go version of operator overloading, there would not be 
conversion involved - a full parse showing differing types on an operator 
operand would thus be illegal. Unless both operands are both implementors 
of the same countable interface, for example, and they either use 
interface{} or a defined interface name as returns/inputs. I think that 
this is a step further on from just allowing redefinition of (some) 
operators to bind to new types, and to allow those types to create 
assignment channels, for example. And this is where the big syntax bugbear 
appears. Overriding an operator is one thing, but defining two types as 
being comparable and assignable with each other will pretty quickly grow 
into a hella boilerplate for a shortcut used 10 times in a 1000 line 
project, and ever growing compilation times.

Go is a simple language, and anything that will take away the simplicity, 
with its benefits in learning, reading and compiling, will and should be 
rejected as an addition to the language spec. I would argue that a small 
set of infix operators and maybe some unarys would not create such 
complexity. Especially if we restrict it to unary post/prefix, addition, 
subtraction equality and assignment, and don't change the precedence rules. 
Really, precedence would not be relevant, and there should not be any 
ambiguity allowed in how an overridden symbol can be used. Precedence 
really only irritates everyone between add/subtract and multiply, square, 
and only for countable types. To stop complexity creeping into the parser, 
also, no change in the rule about casting. No implicit casts. Implicit 
casts are probably one of the most irritating and pervasive features of C 
type languages. I always have to double and triple check. Even between some 
version changes C++ has substantially disrupted the rules about it and I 
just don't think that implicit casting is a good construct in a language. 
Implicit typing through inference does not have this problem.

On Sunday, 23 September 2018 08:35:15 UTC+2, Robert Engels wrote:
>
> Issues like these highlight the deficiencies of Go compared to Java. The 
> Java designers understood languages far better, and from the start realized 
> that identity and reference equality were different concepts. Everyone in 
> Go land are debating these solved issues. Pick and chose what you want to 
> implement but there doesn’t really need to be a debate on how to do it. 
>
> Sent from my iPhone 
>
> > On Sep 22, 2018, at 8:52 PM, Ian Denhardt  > wrote: 
> > 
> >> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote: 
> >> 
> >>   I think the thing everyone who likes 

Re: [go-nuts] Re: Using modules with go test ./...

[Scott Cotton]

Hi @thepudds, 

Good to hear and glad to have followed up so as to have introduced in the 
conversation how to address the concern in that post.

Thanks for the great summary of how to give effective feedback about about 
modules and the general context.

Best,
Scott


On Saturday, 22 September 2018 20:37:51 UTC+2, thepud...@gmail.com wrote:
>
> Hi Scott, all,
>
>> "also I think they have obligated themselves to maintaining support 
> for the current functionality, which some might not
> find fitting to the way they work."
>
> Regarding the concern raised in that post -- I think it is definitely not 
> too late to give feedback on how modules work, even if the core Go team has 
> said they will maintain backwards compatibility for modules.
>
> My understanding of that backwards compatibility is that a module that is 
> defined today will be understood by future Go releases, but that the 
> statement of backwards compatibility does not imply that the exact behavior 
> of modules is frozen (especially for the behavior of the go tool itself, 
> what flags it supports, what those flags do, what does './...' mean, 
> etc.).  Rather, as far as I understand, the exact behavior is *expected* to 
> change based on 1.11 feedback.
>
> For example, from back in February (from the initial detailed vgo blog 
> series):
>
>   > "The details here may be revised, but today's go.mod files will be 
> understood by any future tooling. Please start tagging your packages with 
> release tags; add go.mod files if that makes sense for your project."
>   
> And from the 1.11 release notes:
>
>> "Module support is considered experimental. Details are likely to 
> change in response to feedback from Go 1.11 users, and we have more tools 
> planned. Although the details of module support may change, projects that 
> convert to modules using Go 1.11 will continue to work with Go 1.12 and 
> later."
>
> I read that as saying that the exact behavior of modules may very well 
> change before modules become the default behavior, but that modules defined 
> and released under vgo or Go 1.11 will still be understood.
>
> In other words, feedback is still very valuable and will influence what 
> the behavior is in 1.12 and beyond.
>
> In my personal experience and from what I have observed, the core Go team 
> has been very willing not only to discuss changes to modules, but also to 
> make actual changes to how modules behave based on community feedback.  
> Here is one sample list of changes from the "Modules" wiki page, where 
> almost all of these changes were primarily driven by community feedback I 
> think:
>
>   
> https://github.com/golang/go/wiki/Modules#changes-since-the-initial-vgo-proposal
>
> In terms of the Go 1.11 behavior, there are still open questions, 
> including around what should the exact behavior be when modules are enabled 
> but you are outside of any particular module, or how to best support 
> simultaneously editing multiple modules, or what if any behavior the core 
> tooling might pick up from community tooling such as 
> https://github.com/rogpeppe/gohack, etc.  In many cases, I believe some 
> of the currently open questions were purposefully left as open questions in 
> 1.11, including so that actual experience could better inform future 
> approaches.
>
> Filing module issues or commenting on existing issues is of course 
> valuable, but the core team has also expressed great interest in people 
> filing experience reports on real-world usages of modules. From the 
> experience reports wiki page (
> https://github.com/golang/go/wiki/ExperienceReports):
>
>   "The best experience reports tell: (1) what you wanted to do, (2) what 
> you actually did, and (3) why that wasn’t great, illustrating those by real 
> concrete examples, ideally from production use. Please write these reports 
> about the problems most significant to you, post them on your own blog, or 
> on Medium, or as a Github Gist (use a .md extension for Markdown), or as a 
> publicly-readable Google doc, and then link them here."
>   
> In any event, as a member of the community, I would certainly encourage 
> feedback from other members of the community...
>
> --thepudds
>
> On Friday, September 21, 2018 at 7:57:02 PM UTC-4, Scott Cotton wrote:
>>
>> Hi all,
>>
>> I for one would also consider the interface an improvement if as part of 
>> making modules work outside of a "main module" included making go test 
>> ./... work
>> as before.  Perhaps ./... could mean find each top level module in src/ 
>> and test.
>>
>> I am not sure what the modules implementors would prefer w.r.t. such 
>> feedback.  On
>> the one hand they need it and can't possibly envision how everyone uses 
>> the tooling,  and
>> have wisely called it preliminary.
>>
>> On the other, maybe it's not a bug as modules are defined; also I think 
>> they have obligated 
>> themselves to maintaining support for the current functionality, which 
>> some might not
>> 

Re: [go-nuts] Re: Generic alternatives: new basic types?

[Robert Engels]

Issues like these highlight the deficiencies of Go compared to Java. The Java 
designers understood languages far better, and from the start realized that 
identity and reference equality were different concepts. Everyone in Go land 
are debating these solved issues. Pick and chose what you want to implement but 
there doesn’t really need to be a debate on how to do it. 

Sent from my iPhone

> On Sep 22, 2018, at 8:52 PM, Ian Denhardt  wrote:
> 
>> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>> 
>>   I think the thing everyone who likes operator overloading like mainly
>>   is being able to do infix and postfix syntax, instead of only prefix
>>   (function).
> 
> My own reason for wanting this is not really about syntax, so much as
> being able to define functions etc. which e.g. check for equality,
> without having to write too versions -- one that uses `==` and one
> that calls some method custom types. The syntax isn't really the point;
> there's an underlying notion of equality that we want to be able to talk
> about for more than just built-in types. We could define an interface
> for this:
> 
>// The Equatable interface wraps the basic Equals method.
>//
>// x.Equals(y) tests whether x and y are "the same." The predicate
>// Equals should obey a few common sense rules:
>//
>// 1. It should be reflexive: x.Equals(x) should always return true
>//(for any x).
>// 2. It should be symmetric: x.Equals(y) should be the same as
>//y.Equals(x)
>// 3. It should be transitive: if x.Equals(y) and y.Equals(z), then
>//x.Equals(z).
>//
>// It generally does not make sense for a type to implement
>// Equatable where the type parameter T is something other than
>// itself.
>type Equatable(T) interface {
>Equals(T) bool
>}
> 
> What I am suggesting is merely that `==` desugars to a use of this
> interface.
> 
> An important litmus test for any operator we consider for overloading is
> whether we can come up with a clearly specified interface for it like
> the above. If not, it does not make sense to allow the operator to be
> overloaded, since it is not clear what overloaders should do. I believe
> this is the source of most of the problems with operator overloading in
> other languages.
> 
> I think if we stick to this things will stay under control; there's
> currently nothing stopping folks from defining an instance of
> io.Writer that does something utterly in conflict with what is described
> in its documentation -- but that hasn't seemed to be a problem in
> practice.
> 
> Quoting Michael Jones (2018-09-22 13:14:21)
>>   the reason i wrote something like "...operator overloading, but wait,
>>   don't get excited..." was to bring awareness of a core problem without
>>   (hopefully) having people bring the burden of experience. i say burden
>>   because bad experiences can shadow the 'why' that was good with the
>>   'how' that was bad. let the why foremost to "break these chains, rise
>>   up, and move beyond" as in Callicles' famous speech.
>>   the essential meaning of operator overloading and go interfaces and
>>   Smalltalk messaging is a way to bind code to intent. (in general intent
>>   is named uniquely ("==") for simplicity but that is independent.)
>>   Generics raise the need a way to say how the standard intentions play
>>   out for our types. Imagine our gopher attired as a waiter, politely
>>   asking questions of a custom type:
>> 
>>   gopher: Will you want to test for equality, madam?
>> 
>>   type: Yes, thank you.
>> 
>>   gopher: How would you prefer that test to be done?
>> 
>>   type: Hmm... I'll try 'IsEqualWithOddName(a, b *type)" for now.
>> 
>>   gopher: very good, madam.
>> 
>>   This mutual understanding needs to happen. how is open to discussion.
>>   go interfaces use standard method names. operator overloading uses
>>   standard symbols. macro expansion uses arguments. no matter how it
>>   manifests, the power of generics relies on understanding related parts.
>>   we should talk about what kinds of parts deserve awareness.
>> 
>>   On Sat, Sep 22, 2018 at 8:46 AM Lucio <[1]lucio.d...@gmail.com> wrote:
>> 
> 
>>>   It's good that you brought that up, because another issue I
> remember
>>   from C++ V1.0 days, is that operator overloading did not allow for
>>   changes in operator precedence, an arbitrary sop to some weird
>>   decisions taken in earlier centuries. What I see as pertinent here, is
>>   that precedence is yet another "type" property, this time not of the
>>   arguments to an operator, but the operator itself.
>>   As I pointed out in private correspondence to Ian Taylor, the entire
>>   mess of arithmetic operations ought to be delegated to an APL-like
>>   interpreter and all the complexities, of which being "generic"
>>   functionality is not the only one, becomes one less problem for the Go
>>   compiler. If APL is too obscenely obscure in the Go