Re: [go-nuts] Why Go has only slice and map

[Tyler Compton]

Interestingly, Go also kind of has a built-in set data type by using map
keys! https://go.dev/play/p/3-ZEKPSPUEh

I know that's not really what you mean, but I think it's a cool pattern.

On Tue Apr 12, 2022, 07:50 PM GMT, Ian Lance Taylor  wrote:

On Mon, Apr 11, 2022 at 11:19 PM 'Jack Li' via golang-nuts
 wrote:


Why Go provides only 2 built-in data structures, slice and map. It has just
more than C, but less than all other programming languages I've heard of,
C++, Python, Swift, Rust.

I think this simplicity attracts me very much. Sometimes I can use only one
data structures for a task. Because there is no more similar data
structures for choice. It's really "one way to do one thing". This also
makes code like familiar and consistent.

I want to know more about the mind behind this design of built-in data
structures.


The short answer is that in the early days of Go language features
were added if several programs required them. Many programs needed
slices and maps, so they were added to the language. Both types went
through many permutations in the early days before settling into the
versions we have today. Even very basic operations like "append" were
added after the first release of Go.

No other data structures came up nearly as often as slices and maps,
so no others were added to the language.

Now that generics are in the language, it will be easier for people to
write their own general purpose data structures. We'll see what
people come up with.

Ian

-- 
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVcgKKoapCNuebfyk%2BkaXc3X2sn3h6K5eGGppi7TCdPPA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3JRhf9-zxh%2BftLEHVdRO3dDqg8BetS_%2B_AKrG2AE-9gQ%40mail.gmail.com.

Re: [go-nuts] Whats wrong with my builder pattern

[Tyler Compton]

It's because your method receivers are values, not pointers:

func (b Builder) setFirst() {
b.firstElement = "First element"
}

In Go, method receivers work a lot like regular function arguments. When
you call the above method, you're operating on a copy of the Builder
struct. Any time you pass an argument by value like this, its value is
copied. What you probably want is to define the method on a pointer
receiver:

func (b *Builder) setFirst() {
b.firstElement = "First element"
}

Now, when you call this method on an object, only the pointer is copied.
Inside the method, you're referring to the same Builder instance that you
are when calling the method.

On Sun, Dec 5, 2021 at 10:47 PM Денис Мухортов 
wrote:

> I have 2 empty strings in the output. But why?
> https://play.golang.com/p/v7zEVBM17YH
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/4060a981-f43c-49ec-92f7-849ab23d1ea9n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1Vj2k8-CewHNQmQ%2B3y%3D4cX_Y6w0GORhNmjXTnpWcAfzw%40mail.gmail.com.

Re: [go-nuts] Parse JSON case-sensitively

[Tyler Compton]

Hi Aaron,

I'm not aware of a JSON library that fits your needs, but there might be an XY
Problem  going on here. What problem are you
having trouble solving with encoding/json that lead you to this solution?

On Thu, Sep 23, 2021 at 11:23 AM 'Aaron' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi all
>
> Anyone know of a JSON package (or other solution) which is case-sensitive
> when decoding - and is also mature, simple, and parses into a struct?
> I've looked at a few open-source packages, but the ones I've found seem to
> be focused on performance, or allowing you to access the JSON in different
> ways, or require code-generation, or something.
> Really I just want a drop-in replacement for encoding/json that is case
> sensitive.
> Wondering about forking the package myself... but obviously don't want to
> do that if there's an existing solution.
>
> Thanks
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a3d25416-2490-4719-a38c-9f6a43008184n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0gL-_rB9LHsJdaOLnRMxSZy-zLTFY9mDhxj8jHzHmCcA%40mail.gmail.com.

[go-nuts] Should "go install module@version" interact with ~/.local/bin?

[Tyler Compton]

With recent changes to go install, we now have an official, module-aware
way to locally build and install Go tools. This is a great step, but
I wonder if some renewed consideration should be made to where the tools
are installed.

As I'm sure you all know, go install puts binaries in $GOPATH/bin or
$HOME/go/bin by default. I think that made more sense in a world where the
GOPATH was our primary means of Go development. However, with modules, I
would argue that GOPATH is becoming less and less a part of the Go
development experience. If go install placed binaries in ~/.local/bin by
default instead, it would be more in line with the way other local
installation tools work and wouldn't require users to update their $PATH at
all on some distributions. If we want to keep $GOPATH/bin, perhaps the tool
could put a symlink in ~/.local/bin instead.

I can think of a few reasons why this might not be a good idea:

What about other platforms, like Windows? I don't know if there's a place
in all operating systems where user-installed binaries are supposed to be
installed. It could be argued that the current approach is a better
cross-platform default.

Can't this already be achieved by setting $GOBIN? Sure. I still think
there's value in having the best possible default, but having $GOBIN as an
option makes this discussion less important.

Is this worth the confusion that changes like this inevitably create? Maybe
not. For those of us that use Go daily and already have $GOPATH/bin in our
$PATH, this may seem especially frivlious. I think a change like this
benefits those who don't develop in Go the most, and non-Go developers will
(probably) always outnumber Go developers :)

I'm curious to hear everyone's thoughts.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0c4x5nW80jVehUs666iv%2B_9xp0frEudZH1u5zBHEm%2BjQ%40mail.gmail.com.

Re: [go-nuts] doubts

[Tyler Compton]

It's not clear to me exactly where you're getting stuck. It seems like you
have a reasonable understanding of what you need to do. Could you add some
information on what you've tried so far and where you're getting stuck?

On Sat, Jul 10, 2021 at 10:38 AM Sree lekshmi MG  wrote:

> hey all i am the beginner in golang ,and now  i want to slove *CRUD
> Operations using gin-gonic framework:*
> 1.Create a go service using Gin.
> 2.Connect to mysql database.
> 3.Create End points for all crud operations.
> 4.Write functions for each operation.
> 5.Finally, test it from postman. these type of progrmms can u give me idea
> where i start and what are things i want to slove
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e45b549e-df63-4f8b-b08c-854b8988bf24n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0FvSsxO47OteTmkq-qmPad%2BAJJ%2BbUYzJY%2BE-oMv0aGfQ%40mail.gmail.com.

Re: [go-nuts] UML && Golang, part 2 ?

[Tyler Compton]

Is it true that UML is unpopular? I don't think you'll catch many gophers
writing class diagrams, but I've found higher level UML diagrams useful.

That said, I find UML somewhat overspecified for day-to-day use. A simple
block diagram is often enough for me to explain something to a coworker or
as a piece of supplementary documentation.

On Sun, Jul 4, 2021, 04:16 alex-coder  wrote:

> Ok, folk, as I see UML is not very popular within the community. :-)
> But what do you use instead then ?
>
> Anyway it must be some tool to present the code as a picture.
> The picture is worth a thousand words :-).
>
> Thank you.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/db5362fb-6365-4b88-9b56-98c88cd5cb62n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1T7Gi3puF%2BagkausWFrzONBD8OKX%3DCf-WhRKa2UZ8Aqg%40mail.gmail.com.

Re: [go-nuts] golang/mobile: Could we add GitHub Actions for PRs?

[Tyler Compton]

I'm not a go-mobile contributor, but since the repository is only mirrored
on GitHub and hosted elsewhere I'm not sure if GitHub Actions would be the
right choice. I think they'd reach a CI tool that can have its results
appear both on GitHub and on googlesource.com.

On Mon, Mar 22, 2021 at 8:48 AM Michael Chong 
wrote:

> GitHub Actions  has been introduced
> for a while.
>
> For PRs of go-mobile , only 
> *google-cla
> *is running on GitHub Actions.
> I wonder whether we can add support like automatic testing?
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e6194e76-bd34-40d0-995e-dff5110b98afn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1QTXtUNVe84YK3m3Fe1To9etQGYvd9j1vX6FCWAOBQZQ%40mail.gmail.com.

Re: [go-nuts] A message from the CoC committee

[Tyler Compton]

Thanks Carmen, and others on the CoC committee. I don't think anyone would
say the work you do is fun, but whenever we get these rashes of toxic
behavior on the mailing list or on GitHub, it makes me glad the CoC exists.

On Tue, Mar 23, 2021 at 7:01 AM 'can...@google.com' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Over the last few days, multiple reports were received at
> cond...@golang.org regarding public conduct on golang-nuts, as well as
> conduct in private channels.  After review, permanent bans were given to
> multiple individuals, with no possibility for appeal.  Further corrective
> actions like temporary bans and final warnings are being deliberated,
> pending further investigation.
>
> As stated in our Code of Conduct , we believe
> that healthy debate and disagreement are essential to a healthy project and
> community. However, it is never ok to be disrespectful.
>
> When evaluating a response to a report and making decisions on a
> corrective action, the Go CoC committee takes into account the
>
> * severity of the conduct violation
> * impact of conduct on individuals who report to cond...@golang.org
> * impact of conduct on the community (bystanders, those not directly
> involved in CoC reports)
> * conduct history in all Go project spaces, assessing patterns of behavior
> across multiple sites versus one-off or "most recent only" conduct
> incidents.
> * impact to people of marginalized groups
>
> The last two factors also necessitate a public response, to assure those
> who witness unacceptable behavior, particularly in public places, that
> appropriate and fair corrective action was taken.
>
> We pledge  to make participation
> in the Go project* and our community a harassment-free experience for
> everyone.
>
> Thank You,
> Carmen Andoh
> on behalf of the Go CoC committee
>
> *Go project spaces include all golang-* googlegroups, github/golang/go
> issue repo, and other online forums where the Go CoC is in effect.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/593d282d-5c55-482e-acda-1181850090d4n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1FJMgztUsOh47baf%3DWUmUu1N19XnN_B2i5Cc70x7%2BoKQ%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Tyler Compton]

Believe it or not, that wasn't my intention at all. There certainly are
other people unhappy with the generics proposal, and they were burned too.
I was attempting to acknowledge your position compassionately while also
arguing that things aren't nearly so bad as you say.

Unfortunately, it seems you're determined to be the victim here as
evidenced by your continual misreading of peoples responses. I'm also
giving up on this thread.

On Fri, Mar 19, 2021, 04:54 Space A.  wrote:

> Ok so this is a nice post. What you are trying to do with it is to make an
> impression that there is only I in the whole Universe who was unhappy with
> that proposal.
> It's not true. Open the issue and read down below comments by other
> people. Some others who might also wanted to give their feedback can't do
> this because it was locked and there is no intent to listen to them.
>
> > Go team created a proposal that a large enough number of Go users found
> beneficial for it to be accepted
> 1. Since some time I don't know what "Go team" is. As Google put a
> trademark on Go, and its own label on golang.org website, so they
> obviously wanted that everyone was aware of who stands behind the project,
> it would be correct to say "a group of Google employees".
> 2. Sure, Ian has revealed how that "consensus" was measured. By counting
> "thumbs up", "thumbs down" and "confused" emojis. So Go is not driven by
> polls, it's driven by emojis.
>
>
>
>
> чт, 18 мар. 2021 г. в 23:22, Tyler Compton :
>
>> I think we all want to stick our noses in this thread. I'm going to stick
>> my nose in it too :)
>>
>> Space, I don't think you'll ever be happy as a result of this discussion,
>> no matter what evidence or arguments others provide you. I think the fact
>> is that you were burned by the outcome of the generics proposal. You didn't
>> have the time to review the draft proposal and engage with the discussion
>> early, and you disagree with the resulting outcome. That's unfortunate and
>> I'm sorry it happened. I hope you don't feel that people are trying to
>> convince you that you weren't burned. Nothing feels worse than having your
>> concerns trivialized.
>>
>> However, you have to understand that just because you were burned doesn't
>> mean that those around you making these decisions are bad actors. There are
>> probably small ways that this process could have been improved, but I don't
>> think they would have changed the outcome. The reality is that after many
>> iterations, the Go team created a proposal that a large enough number of Go
>> users found beneficial for it to be accepted. I know you disagree with
>> them, but our responsibility as members of this community is to
>> exercise our right to disagree without resorting to attacks on character. I
>> hope I've been able to address your concerns and disagree with you without
>> making you feel I'm attacking your character.
>>
>> To those who are still attempting to provide evidence that the generics
>> proposal process was conducted in good faith, I think you've done
>> everything you need to do and it's probably best to just let this one go.
>>
>> On Thu, Mar 18, 2021 at 7:08 AM Space A.  wrote:
>>
>>> Since pro-generics ppl here are struggling to provide any evidence of
>>> existence of open and public discussion on the topic of dropping generics,
>>> I will do it myself.
>>>
>>> Here is it:
>>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>>>
>>>
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu14%2B2YuGzaOfuazhAL3D62B1Gd3kjhmnV2U1sY_KqLdXA%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Tyler Compton]

I think we all want to stick our noses in this thread. I'm going to stick
my nose in it too :)

Space, I don't think you'll ever be happy as a result of this discussion,
no matter what evidence or arguments others provide you. I think the fact
is that you were burned by the outcome of the generics proposal. You didn't
have the time to review the draft proposal and engage with the discussion
early, and you disagree with the resulting outcome. That's unfortunate and
I'm sorry it happened. I hope you don't feel that people are trying to
convince you that you weren't burned. Nothing feels worse than having your
concerns trivialized.

However, you have to understand that just because you were burned doesn't
mean that those around you making these decisions are bad actors. There are
probably small ways that this process could have been improved, but I don't
think they would have changed the outcome. The reality is that after many
iterations, the Go team created a proposal that a large enough number of Go
users found beneficial for it to be accepted. I know you disagree with
them, but our responsibility as members of this community is to
exercise our right to disagree without resorting to attacks on character. I
hope I've been able to address your concerns and disagree with you without
making you feel I'm attacking your character.

To those who are still attempting to provide evidence that the generics
proposal process was conducted in good faith, I think you've done
everything you need to do and it's probably best to just let this one go.

On Thu, Mar 18, 2021 at 7:08 AM Space A.  wrote:

> Since pro-generics ppl here are struggling to provide any evidence of
> existence of open and public discussion on the topic of dropping generics,
> I will do it myself.
>
> Here is it:
> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo/m/-EZp3YSeBQAJ
>
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d8b96595-effe-4eed-898d-1c4e183189dbn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3GpLa38KPKt_M_Sk5PBDq0MAuK8MbZqkddfuYTr4E7Bg%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Tyler Compton]

I would also add that there was an old generics design draft based around
contracts [1] that was not accepted for multiple reasons, but one was that
it wasn't clear how the implementation could actually work. This suggests
that implementation issues are definitely considered during the proposal
process, even if they're considered more quietly than other issues.

1.
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md

On Fri, Mar 12, 2021 at 1:05 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> The title of your message seems to indicate that you are looking for
> arguments not to implement generics. You should be aware that the
> proposal to add generics has been accepted
> , so
> the discussion of whether or not Go will get generics is answered. For
> better or for worse.
>
> With that in mind: I am not aware of any extensive or formal evaluation
> like the one you are looking for. And I don't think it is common to do such
> an evaluation for any language change proposal in Go, beyond what
> individuals estimate for projects they take on and the Go team planning
> their workload. It is possible someone on the Go team (or someone else) has
> more data though.
>
> The discussion went on for several years and included many of the people
> working on the official Go compiler. The consensus seems to be, that the
> work required is not unreasonable. I am not personally aware of any of them
> raising concerns about the workload (though I might have missed something
> and/or I might've not been aware that someone voicing a concern was working
> on the compiler, so take that with a grain of salt).
>
> As for third-party implementations: In general, it is up to the respective
> projects if and how they want to implement language changes. Planning that
> is not usually done in the context of the Go project. That being said, over
> the past 3 years or so there was plenty of occasion for any third party
> implementer to voice any concerns. I am not personally aware of any of them
> doing so (same caveats as above).
>
> My own uneducated guess is that implementing the design is not
> prohibitively difficult. The syntactical changes are very small. The type
> inference algorithm is fairly simple. And a simple implementation can
> instantiate the generic types and functions early in the frontend, without
> having to modify many internals. Generics are a big language change in
> terms of expressive power of the language and a language change in terms of
> amount of discussion to get it right. But I suspect in terms of changes to
> the spec and implementations, it will be a surprisingly small change.
>
> I'm sorry for a whole lot of "I don't know" - and maybe someone who knows
> more will add more. But as someone who was pretty actively participating in
> the discussion for the past several years, I wanted to re-assure you that
> "it is too much work to implement" is not really a concern shared by many,
> as far as I can tell :)
>
> On Fri, Mar 12, 2021 at 4:31 PM alex-coder  wrote:
>
>> Hello again,
>> I apologize for being so intrusive.
>> Where it is possible to read about the evaluations of labor and
>> complexity for
>> GO itself for different implementations to introduce generic in GO ?
>>
>> Thank you.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/64e6d441-3564-49ab-9f97-233eda3ea682n%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEE%3DHbr%3D2HzsWA21GQdkXj33iqRJvT6jO_wHC-X-U1%3DBg%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu18%2B%3Du3q16kM%2BURBxckvXz5mTed3EiysT4P4yZnWccY%2BA%40mail.gmail.com.

Re: [go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

[Tyler Compton]

You could imagine a `slices` standard library package that has a regular
generic function called `slices.Remove` that removes one or a series of
elements. This seems like a smart addition to me, as the current de-facto
method isn't very expressive. I imagine this didn't exist before
because adding a new built-in function has a far higher cost than adding a
simple utility function to a package.

On Thu, Feb 4, 2021 at 4:48 PM Uli Kunitz  wrote:

> Hi,
>
> You can always do a = append(a[:3], a[4:]...).  If you want to remove 2
> elements a = append(a[3:], a[:5]). You would need to call remove two
> times, which is slower and cumbersome.
>
> I have rather have two functions like copy and append than a dozen that I
> have to learn. One of the Go Proverbs is "The bigger the interface the
> weaker the abstraction."
>
> Greetings, Uli
> On Friday, February 5, 2021 at 12:55:36 AM UTC+1 selahad...@gmail.com
> wrote:
>
>> Hi,
>> I wonder if there are any proposals for the Remove method for Slices,
>> which removes an element from a Slice.
>>
>> Since the status of the latest generics draft is `likely accepted` and
>> it'd be possible to implement this with `generics`. I believe such an
>> addition to language would alleviate the need to `loop + swap + resize`
>> each time, and enhance the overall readability since there is a consensus.
>>
>> This may seem trivial, but I want to highlight some examples from other
>> langs just to further* concretize*:
>> arraylist.remove(object o) => java
>> list.remove(val) => python
>> array.remove(at: 0) => swift
>>
>> I have looked for the proposals for Go 2 but couldn't find any regarding
>> this issue.
>>
>> There are obviously more things to consider, like whether the operation
>> should keep the order.
>>
>> I'd be very happy with your responses to this pseudo-proposal.
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a7864041-2484-4664-9b2f-1578384defe0n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3KW5F0AspbZMX-RMkG35xMJ-hfBwcgU8cmSuQiDy57%2Bg%40mail.gmail.com.

Re: [go-nuts] R.I.P. Michael Jones

[Tyler Compton]

Thank you Jan for posting this. From his incredible accomplishments to his
day-to-day friendliness and insight on this mailing list, he will certainly
be missed.

On Thu, Feb 4, 2021 at 3:13 PM Jan Mercl <0xj...@gmail.com> wrote:

>
> https://www.geospatialworld.net/blogs/goodbye-michael-jones-the-man-who-gave-the-power-of-maps-in-our-hands/
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-WMyrNU32vXVD4%2B0iMwSCRgvP5ZeP-W9oV6%2BiyprgfjGA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3_qsJfe6Q0RzoP%2BGCv%3D57jsruTTue78NCAOvoceqSCBQ%40mail.gmail.com.

Re: [go-nuts] Gopls enabled by default in VSCode

[Tyler Compton]

I can't find the announcement off hand, but I remember gopls being
announced as stable at least a few months ago. Like Brian, I think this
documentation needs to be updated.

Anecdotally, I was around and using gopls back when it was definitely not
stable. It's gotten leagues better and now I have no problems with it. I
wouldn't worry about gopls.

On Mon, Feb 1, 2021 at 12:15 PM 'kale...@googlemail.com' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> This twitter announcement was made today about the Gopls language server
> being enabled by default in the VSCode editor.
>
> https://twitter.com/golang/status/1356289079575506950
>
> Is this a wise move, seeing as though the documentation for Gopls states:
>
> "It is currently in *alpha*, so it is *not stable*."
> Source: https://pkg.go.dev/golang.org/x/tools/gopls
>
> Why is a piece of software that is in alpha and not stable being enabled
> by default in an editor used by a large number of Go developers. This
> should be 'opt-in' until the language server is stable.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5bd5743d-fbc5-402b-bf04-e13e6daa34f8n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0aocchurJmuZo6gKpF7ZuZT5%3D-Y3%3DM%3DKOEUMKuNo398A%40mail.gmail.com.

Re: [go-nuts] [ANN] New Go package: xmorph

[Tyler Compton]

That GIF makes me very happy. It reminds me of the Animorphs book covers
made with Elastic Reality :)

On Mon, Jan 18, 2021 at 12:24 PM Scott Pakin  wrote:

> It's perhaps a bit of a niche tool, but I just released *xmorph*, a
> package for warping and morphing images.  The code is available from
>
> https://github.com/spakin/xmorph
>
> (If nothing else, you can see there my crude attempt at morphing the
> cartoon Go gopher into the corresponding plush toy.)
>
> The Go package is essentially a wrapper for the C libmorph library (
> http://xmorph.sourceforge.net/), which is what the morph CLI and the
> xmorph and gtkmorph GUIs build upon.
>
> Enjoy!
>
> — Scott
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9e89e277-8e36-45e0-97a0-098dce8b908en%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1dTNNxyRAHEyEPb8AWp0ne%2B90dPydf1RYm6EGHFBPubg%40mail.gmail.com.

Re: [go-nuts] an open source project to replace SMTP/email

[Tyler Compton]

Seems cool Liam, thanks for sharing!

On Tue, Jan 5, 2021 at 2:30 PM Liam  wrote:

>
> The mnm project is building a legitimate email replacement: a client[1], a
> server[2], and a simple protocol[3] between them. (Legitimate, i.e.
> n-identity, decentralized, store-and-forward, open protocol, open source.)
>
> https://mnmnotmail.org
> https://twitter.com/mnmnotmail
>
> Both client and server are written in Go. The client UI runs in a
> localhost browser tab, rendered by Vue.js. The client has had nine preview
> releases since Spring 2019.
>
> Contributors welcome!
>
> [1] https://github.com/networkimprov/mnm-hammer
> [2] https://github.com/networkimprov/mnm
> [3] https://github.com/networkimprov/mnm/blob/master/Protocol.md
>
> PS: Ambitious? Yes and no. Establishing a new protocol is a process, but
> email as we know it is headed for extinction, because phishing has made it
> a trivial cybercrime portal.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/138ffba1-db87-41e5-8e22-731f410eb971n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1F-EAARo7Spyv5J8vr1jicJS8m1DQ1sGgtdw%3DhLub7bQ%40mail.gmail.com.

Re: [go-nuts] The GitHub Vet Project

[Tyler Compton]

>
> This is a valid concern but since the tool remains under active
> development, I would caution against making an assessment based on the
> number of issues currently reported in the tracker.
>

Fair point! I'll reserve judgement in that case then.

On Wed, Dec 30, 2020 at 9:57 PM K. Alex Mills 
wrote:

> On Wed, Dec 30, 2020, 10:34 PM Tyler Compton  wrote:
>
>> This is a very interesting project! I went ahead and labeled a few of the
>> issues. However, much as I hate to pour cold water on the idea, I have some
>> doubts about how effective this approach can be. The githubvet bot has
>> reported over ten thousand issues so far, which is quite a lot.
>>
>
> This is a valid concern but since the tool remains under active
> development, I would caution against making an assessment based on the
> number of issues currently reported in the tracker.
>
> Part of the problem is that the current tracker contains issues from
> multiple runs, since I've rescanned during testing, as I find and fixing
> issues.
>
> There are still some things that can be done to bring down the
> false-positive rate, but before addressing that I need to spend time on
> some of the false-negatives that I am currently aware of.
>
> My gut feeling is that if code does exist that correctly relies on the
>> current behavior, it would be extremely subtle. If we're going to get
>> through all of these issues, we won't be able to give each example a
>> complete deep dive which I think means we'll likely miss very subtle cases.
>> Not that I have any better ideas :)
>>
>
> Part of the hope has been that a large number of community participants
> would help parallelize the effort and (perhaps) even get multiple pairs of
> eyes on each issue. Whether that will work or not remains to be seen.
>
> I will also say that many of the issues I have looked at have seemed to be
> classifiable rather quickly. OTOH, that could also be an indication that
> the false-positive rate remains a little high.
>
> All that said, so far, the issues reported only focus on race-conditions
> or incorrectly storing a reference to a range-loop pointer. Tim King has
> just pointed out a few other concerns like pointer comparison and
> finalizers for which analyzers have yet to be written. My perception is
> that these two features aren't very widely used, so I wouldn't expect to
> find a large number of instances like these.
>
>
>> On Sun, Dec 20, 2020 at 12:38 PM K. Alex Mills 
>> wrote:
>>
>>> Hello Gophers!
>>>
>>> During a Q&A session at this year's GopherCon, some members of the Go
>>> language team indicated a willingness to modify the behavior of range
>>> loops <https://github.com/golang/go/issues/20733> *if* we can be
>>> reasonably certain that the change will not cause incorrect behavior in
>>> current programs. To make that determination, a large collection of
>>> real-world go programs would need to be vetted. If we can find that, in
>>> every case, modifying the compiler behavior does not lead to an undesirable
>>> outcome, we will have strong evidence that the change may only have a small
>>> impact.
>>>
>>> I've been working on a project to gather and crowdsource data for that
>>> sort of analysis. It has reached a point where I think that it's time to
>>> share it with the Go community.
>>>
>>> The GitHub Vet Project <https://github.com/github-vet> performs static
>>> analysis on public Go repositories hosted on GitHub in order to better
>>> understand the impact of this proposed language change
>>> <https://github.com/golang/go/issues/20733>. It consists of two bots.
>>> VetBot crawls GitHub to snippets of code it thinks could be interesting, it
>>> reports it as an issue in a separate repository
>>> <https://github.com/github-vet/rangeloop-pointer-findings>, for humans
>>> to analyze via crowdsourcing. TrackBot
>>> <https://github.com/github-vet/bots/tree/main/cmd/track-bot> manages
>>> the crowdsourcing workflow.
>>>
>>> At this point, all of the features I think are necessary for the
>>> project's success have been implemented. But I am only one Gopher, and so I
>>> would like to a) make the community aware of the project and b) ask the
>>> community to help review it in three ways:
>>>
>>> 1) Test out TrackBot and the project instructions by actually
>>> crowdsourcing through the issues found so far
>>> <https://github.com/github-vet/rangeloop-pointer-findings

Re: [go-nuts] Generics - please provide real life problems

[Tyler Compton]

Space A,


> So switching from subject to my personality and telling me what I should
> and what shouldn't, to whom to listen, and what to read is something in
> line with "code of conduct" which you appeal as the argument of last resort?
>

I've seen how you carry yourself on this list, and you really should read
the code of conduct. I think your arguments would gain quite a bit more
traction on this list if you presented them in a more respectful way.

On Wed, Dec 30, 2020 at 3:47 PM Space A.  wrote:

> Nice.
>
> > You should listen to people who have been doing this much longer than you
> Thanks, are you sure you know for how long I've been doing *this* to be
> able to compare?
> > before discarding all their points as "bullshit"
> Have *you* actually read and listened because this is not what I've said?
> > and you should probably review the community code of conduct
> So switching from subject to my personality and telling me what I should
> and what shouldn't, to whom to listen, and what to read is something in
> line with "code of conduct" which you appeal as the argument of last resort?
>
>
> This was actually my first comment on this particular topic. So yea, I
> read and listened before replying. I could have replied to everyone and
> explained in detail, but I value the time of my opponents. And my own time,
> tbh.
>
>
> чт, 31 дек. 2020 г. в 00:03, David Riley :
>
>> This topic has shown little other than that a few people here are
>> unwilling to consider points of view other than their own and declare that
>> very real problems are not real.
>>
>> You should listen to people who have been doing this much longer than you
>> have before discarding all their points as "bullshit", and you should
>> probably review the community code of conduct.
>>
>> If you've got nothing constructive to contribute, why bother?
>>
>>
>> - Dave
>>
>>
>> > On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
>> >
>> > "runtime type-casting"
>> > "type safety something"
>> > "boilerplate"
>> > "amount of code"
>> > "benefit something"
>> > "greatly simplified" (for whom?)
>> >
>> > This topic has clearly shown that most people pro-generic have no *real
>> world* problems that they struggle to solve, yet most of them don't even
>> understand what *real world* problems are.
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0nbJE9q3P46rEkRjo5nhWPkevJT1DYY2H39zkQhQEM%3Dw%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Tyler Compton]

Hi Martin,

You've been very willing in this thread to listen to feedback, and I
appreciate that. I hope it doesn't feel like I'm ganging up on you, but I
want to comment on one other point I disagree with in your original premise.

I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>

This kind of sentiment is something I often see when discussing generics.
It's worth pointing out that the original creators you mentioned are still
at least somewhat involved with Go's development and would make it known if
they believe the current generics proposal violated the spirit of the
language. Generics have been left as an open question on the FAQ
 for a very long time. These things
don't make an argument for generics on their own, but they do suggest that
Go's original team was and is not dead set against generics, for what
that's worth.

On Wed, Dec 23, 2020 at 11:15 PM Martin Hanson 
wrote:

> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/19560461608790506%40sas1-75175cadc2b3.qloud-c.yandex.net
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0y2TqL6rCODoiJD%3D1n8wuGawM7jZw9-zfqD5Sx_oRttg%40mail.gmail.com.

Re: [go-nuts] The GitHub Vet Project

[Tyler Compton]

This is a very interesting project! I went ahead and labeled a few of the
issues. However, much as I hate to pour cold water on the idea, I have some
doubts about how effective this approach can be. The githubvet bot has
reported over ten thousand issues so far, which is quite a lot. My gut
feeling is that if code does exist that correctly relies on the current
behavior, it would be extremely subtle. If we're going to get through all
of these issues, we won't be able to give each example a complete deep dive
which I think means we'll likely miss very subtle cases. Not that I have
any better ideas :)

On Sun, Dec 20, 2020 at 12:38 PM K. Alex Mills 
wrote:

> Hello Gophers!
>
> During a Q&A session at this year's GopherCon, some members of the Go
> language team indicated a willingness to modify the behavior of range
> loops  *if* we can be
> reasonably certain that the change will not cause incorrect behavior in
> current programs. To make that determination, a large collection of
> real-world go programs would need to be vetted. If we can find that, in
> every case, modifying the compiler behavior does not lead to an undesirable
> outcome, we will have strong evidence that the change may only have a small
> impact.
>
> I've been working on a project to gather and crowdsource data for that
> sort of analysis. It has reached a point where I think that it's time to
> share it with the Go community.
>
> The GitHub Vet Project  performs static
> analysis on public Go repositories hosted on GitHub in order to better
> understand the impact of this proposed language change
> . It consists of two bots.
> VetBot crawls GitHub to snippets of code it thinks could be interesting, it
> reports it as an issue in a separate repository
> , for humans to
> analyze via crowdsourcing. TrackBot
>  manages the
> crowdsourcing workflow.
>
> At this point, all of the features I think are necessary for the project's
> success have been implemented. But I am only one Gopher, and so I would
> like to a) make the community aware of the project and b) ask the community
> to help review it in three ways:
>
> 1) Test out TrackBot and the project instructions by actually
> crowdsourcing through the issues found so far
> .
> 2) Review the output
>  and
> raise concern if anything that I claim ought to be excluded
> 
> is somehow making it through.
> 3) Static analysis experts: review the analyzers
>  and ruthlessly
> question anything that could lead to a false negative. I don't think
> anything exists, but one pair of eyes is often wrong, and there are many
> folks on this list with (much) more expertise than me.
>
> One final thing. The crowd-sourcing workflow I've designed relies on the
> opinion of experts to help estimate the reliability of the community
> assessment. In order for that to work, I need the help of some Go experts
> who are willing to commit some time to reviewing the findings. If you'd
> like to participate in this way, first, read the TrackBot documentation
>  to
> understand what being an expert entails. If you're still interested, email
> me with the subject line 'GitHub Vet Expert' and include your GitHub
> username and a brief outline of your experience with Go.
>
> It's my hope that this project can provide some data that can help to move
> Go forward. To that end, I'm also interested in any and all feedback and
> suggestions. Contributions are also welcome
> .
>
> Thanks for reading,
>
> K. Alex Mills, Ph.D
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CALJzkY86ZgQMQBqiAyDOKHHionjLZJbB6f%2BEDcMp82ZaPCKmXw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1WD91GT6noa8bG1%3DjVaYBbugezt0gK4ESvu%2BJEzkVgsw%4

Re: [go-nuts] Re: Garbage Collector triggering when deleting an object

[Tyler Compton]

If you're using finalizers to clean up C memory, it's important to know
that the Go garbage collector has no understanding of how much C memory a
given resource holds. This prevents the garbage collector from making smart
decisions about when to release your resources. I've never personally seen
this become an issue, but it's something to keep in mind.

On Mon, Nov 23, 2020 at 4:32 AM tokers  wrote:

> Are there any documents?
>
> On Monday, November 23, 2020 at 7:28:31 PM UTC+8 Tamás Gulácsi wrote:
>
>> There is a runtime.SetFinalizer, but it is not guaranteed to be run,
>> anytime.
>> The most idiomatic and safe solution is to have a Close() method on the
>> Go side, which frees the C side.
>> You may even add a Finalizer that panics if Close haven't been called
>> before...
>>
>> tokers a következőt írta (2020. november 23., hétfő, 4:17:18 UTC+1):
>>
>>> There is a runtime.SetFinalizer function.
>>>
>>> On Sunday, November 22, 2020 at 8:13:22 PM UTC+8 Sean wrote:
>>>
 I am writing a Golang wrapper for OpenAL-Soft.
 I need to create some buffers. These operations are happening on the
 OpenAL-Soft side (So C functions). I am loading PCM data into buffers.

 Can I set up a trigger mechanism like "x.__del__" as in Python?

 I can set the garbage collector to follow some objects.
 But I have to call some C functions (alDeleteBuffers) to delete buffers
 in OpenAL.

 I want garbage collector to run this function while deleting the
 object.

 Is this possible?

 --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/97bafe0a-46a6-46ba-8aeb-fa875bf80b58n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3T29PH%2BPgxjBFFCwVrYkSbUv5tKFk5GR%2Bbk1YZmvK5tw%40mail.gmail.com.

Re: [go-nuts] Is it possible that a hybrid memory management could be implemented?

[Tyler Compton]

I may be misunderstanding what you're suggesting, but I believe Go already
tries to detect when a value can be placed on the stack. Then, it will be
freed automatically when it falls out of scope.

On Sun, Nov 15, 2020 at 5:20 PM tapi...@gmail.com 
wrote:

>
> For example, some local memory allocations could be detected no used
> elsewhere so that they can may be freed immediately when out of reach
> instead of waiting to be freed in the GC phase.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5c38b239-fe56-44ce-aaf6-61636a682707n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0-AydQ0K1GO_-fibaEqNGAN-dAQk%3DL4LAmNVAmTta8yw%40mail.gmail.com.

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

[Tyler Compton]

Some thoughts:

The "try proposal" and some others identified and solved two problems:

a. The verbosity of using a full if statement to check error values
b. The verbosity of applying wrapping and other error handling logic to
every place where an error is returned

This proposal only addresses Problem A. Maybe that's okay, because it seems
like addressing Problem B often leads to complicated control flow issues.

I do like that this proposal doesn't treat errors in a special way. I could
imagine it could be useful when checking if a key is in a map, for example.

value, ok := myMap["value"]
returnif !ok, errors.New("Oh no! Missing key 'value'!")

Another thought: Should returnif allow a statement before the boolean
expression like if does?

returnif value, ok := myMap["value"]; !ok, errors.New("Oh no!")

That could make code more compact but looks very busy to me. My first
impression is that this shouldn't be allowed.

I think I would be okay with reading and writing code like this. The level
of complexity here is certainly lower than other proposals, although the
value is arguably lower as well since it doesn't solve as many problems.
I'll defer to others here.


On Mon, Nov 9, 2020 at 1:52 PM Jeremy French  wrote:

> Hm, yep. Very similar. Interestingly, the only cohesive objections I can
> see in those threads are to the minor details that are different from what
> I'm saying. Still, though - at least the idea has been presented before.
>
> Jeremy French
> 607-444-1725
>
> On Mon, Nov 9, 2020, 2:57 PM Ian Lance Taylor  wrote:
>
>> On Mon, Nov 9, 2020 at 11:20 AM Jeremy French  wrote:
>> >
>> > First, the caveat.  I know error handling is a long-standing
>> discussion.  I know there has been lots of debate on error handling, and it
>> can seem like there are no more new ideas to be had on the topic.  And I
>> have looked at several/most of the most popular proposals, and there are
>> quite a few that bear similarity but are critically different in important
>> aspects to this proposal. If this has been proposed before with the same
>> effective fingerprint, I haven't been able to find it after several hours
>> of due diligence.  I'm interested in hearing any and all (well-reasoned)
>> thoughts on the matter, but if there's a flaw in my logic, I don't see it
>> yet.
>> >
>> > In short, the proposal is to create a conditional return statement,
>> e.g. "returnif" of the form:
>> >returnif [bool], [returnvalue],...
>> >
>> > This is syntactic sugar for:
>> > if [bool] {
>> > return [returnvalue],...
>> > }
>> >
>> > of which, the immediate benefit is:
>> > returnif err!=nil, err
>> >
>> > or alternatively:
>> >
>> > returnif myErrorChecker(err), myErrorWrapper(err, "Some text.")
>> >
>> > Here's my reasoning.  Go Error Handling in is current form is extremely
>> correct, precise, explicit, and clear.  All very good things.  Really the
>> only problem with it is the repetitious verbosity.  A programmer's
>> instinctive reaction to repetitious verbosity is to wrap it in a function.
>> The infamous "if err != nil {return err}", although repetitious and
>> ubiquitous, cannot effectively be encapsulated to "return
>> someErrorChecker()", because the return statement is unconditional.  Once I
>> start a statement with return, nothing I can do later in the statement or
>> within a called function can change whether or how that return alters flow
>> control.  This, I think, is the quintessential problem with the current
>> error handling methodology.  This proposal addresses that without
>> sacrificing any of the good things about error handling in Go.  Error
>> handling is still explicit.  Errors can still be treated as values. Proper
>> error handling and annotating is blessed but optional. The behavior of
>> defer is unaffected.  It is still simple to understand, and easy to read.
>> And it's entirely backwards compatible.
>> >
>> > Also, while the most obvious benefit is in error handling, this is not
>> technically just an error handling solution. It is completely unopinionated
>> on the type of values it returns, or whether they qualify as an error or
>> not.  I can foresee enterprising gophers finding other uses for this
>> keyword, and quite possibly even new useful design patterns could emerge as
>> a result.
>> >
>> > Possible Objections:
>> >
>> > It could be seen to violate the "one way to do things" principle.
>> However,
>> >
>> > It violates this rule much less than almost all of the other proposals
>> for error handling.
>> > If, under the covers, it's just code substitution, then there's still
>> only one actual avenue of execution in the compiled objects.
>> > There is precedent for this type of shortcut when the benefits are so
>> widespread and the sugar improves readability. For example,
>> > } else if isTrue {
>> > doSomething()
>> > }
>> > is sugar for
>> > } else {
>> > if isTrue {
>> > doSomething()
>> > }
>> > }
>> >
>> > "It's just a variation on other existin

Re: [go-nuts] A Big Thank You to the Contributors of pkg.go.dev

[Tyler Compton]

Agreed! There was a lot of negativity surrounding pkg.go.dev regarding
license detection and the original decision for it to be closed source
(which was revised). These are all valid critiques, but they unfortunately
overshadowed how great an experience pkg.go.dev is. Thanks to everyone who
is working on it!

On Tue, Nov 10, 2020, 06:26 Joseph Lorenzini  wrote:

> Hi all,
>
> I was looking up some documentation for a go package and I was
> redirected to pkg.go.dev. Unlike godoc, it doesn't have an index which
> is my go-to for exploring the API surface of a package. I wondered if
> others had the same problem. Came across
> https://github.com/golang/go/issues/41587 which led me to
> https://beta.pkg.go.dev. Lo and behold the index is back!
>
> This is fantastic and I can't say enough good things about the
> redesigned site. It's fast, easy to search, and the UX makes it just
> as easy to explore the API of a package as godoc did.
>
> Like any community around open source software, most of the
> conversations are about problems users are having and shortcomings in
> that software. Sometimes though I think it's a good thing to let
> people know that they did a good job and the work is appreciated.
> Might even help with open source contributor burn out.
>
> Thanks,
> Joe
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMvD0VJP52L3QHMTLhYMHEAH_f-QMvOS0SsZL%2BD9%2BQUNtqMnqg%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2kYq8T758y-m4PN2Fp1gXqakDDNc6AbVHBaAOW4sRvAA%40mail.gmail.com.

Re: [go-nuts] go list "go:generate" files

[Tyler Compton]

I know that you're asking about how to do this with the standard tools, but
you can do this with grep if you're on a platform that has the command
available:

grep --recursive --files-with-matches "//go:generate"

or, for short:

grep -rl "//go:generate"

This command will output a list of files with "//go:generate" in them,
separated by newlines. Might be a good alternative if there's no way to do
this with the go command.

On Mon, Nov 9, 2020 at 8:00 AM gta  wrote:

> Hello,
> is there a way to list all the files that have a `//go:generate` directive
> with the standard tools?
> I see that `go list` can show the ignored files so I am assuming it is
> detecting `// +build ignore` directives, but I found nothing to lit the go
> generate target files.
>
> Thanks in advance,
>
> Giacomo
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c45f0126-dd61-444d-a351-729132bf25fdn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2q7T0tCkWaRTiQ4DyCqROVFKrN5q%2BncFb7Qgd%2BBTgXpQ%40mail.gmail.com.

Re: [go-nuts] Syntactic Sugar Idea for Go 2.0: until/unless, and postfix conditionals

[Tyler Compton]

Thanks, Dan. Those seem like well-reasoned points.

On Mon, Nov 2, 2020 at 9:33 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> There are two parts. The worse part is the negative conditional
> (unless), which has the problem that humans are bad at negations;
> nearly always when there is a complex condition with an "unless", it
> needs to be mentally refactored into an "if !" (when working through
> other people's bugs, I invariably — at least temporarily — inverted the
> condition and replaced the "unless" with an "if").
>
> The post-fix conditional syntax says a whole heap of stuff that's going
> to happen, and only when you get to the end of the line do you see that
> it might not.
>
> Putting a single positively oriented syntax, at the front of
> conditional blocks greatly simplifies the thinking about what is going
> to happen in a section of code.
>
> On Mon, 2020-11-02 at 21:22 -0800, Tyler Compton wrote:
> > I don't think I'm personally sold on this proposal either, but I'm
> > curious what bad experiences you've had with post-fix conditionals. I
> > haven't personally used a language with post-fix conditionals and it
> > sounds like that might be to my benefit :)
>
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/81c874ec04cea0e9e8f73d251cccf01cfa9b9e19.camel%40kortschak.io
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1BdVrmx9kjkxPH%3DrTvVHgFyiYN_RMH1uM7YXoj2zyXHg%40mail.gmail.com.

Re: [go-nuts] Syntactic Sugar Idea for Go 2.0: until/unless, and postfix conditionals

[Tyler Compton]

I don't think I'm personally sold on this proposal either, but I'm curious
what bad experiences you've had with post-fix conditionals. I haven't
personally used a language with post-fix conditionals and it sounds like
that might be to my benefit :)

On Mon, Nov 2, 2020 at 9:09 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> My first professional programming language was Perl, decades later I
> still wake up in a sweat thinking about post-fix conditionals and the
> 'unless' conditional.
>
> Please no.
>
> On Mon, 2020-11-02 at 14:26 -0800, Jeffrey Paul wrote:
> > Hello Gophers,
> >
> > There's two tiny pieces of syntactic sugar I really miss from a few
> > other languages that I think would add a nice bit of ergonomics and
> > convenience to Go (which I now play as my main) without increasing
> > any magic or spooky action at a distance.
> >
> > They are:
> >
> > - postfix conditionals
> >
> > and
> >
> > - until (while!) and unless (if!) (which probably also means adding
> > `while`)
> >
> > This allows for lovely expressions such as the following examples:
> >
> >i.NotifySomeone() if j.HasExpiredItems()
> >
> >time.Sleep(1 * time.Second) until thing.IsReady()
> >
> >b.ReportActivity(e) unless u.HasOptedOut()
> >
> >q.ProcessItem() while server.Active()
> >
> >until(time.Now().After(notAfter)) {
> >   // do something while we still can
> >}
> >
> >p.processEvents() until p.shutdownRequested
> >
> > and, my favorite:
> >
> >panic("can't even") if err != nil
> >
> > There are, of course, various ways of doing some of this sort of
> > synchronization stuff in these contrived examples using
> > channels/goroutines/timers, but this sort of syntax is quite useful
> > for simple straight-line synchronous code, and, in my view, increases
> > readability without sacrificing anything.
> >
> > I know that `while` isn't a distinct thing in Go, and for
> > consistency's sake, this might necessitate adding such a construct as
> > well (if you can use it as a postfix conditional, you should probably
> > be able to use it as `while(cond) {}` too).
> >
> > What do you think?  I really miss this syntax from other
> > languages.  It's been in Perl and Ruby for ages, and, more recently,
> > CoffeeScript had it for a moment, but it didn't make it over into ES
> > with the other notable features from it.  I think it's a lovely
> > convenience without changing the operation of the language itself.
> >
> > Best,
> > -sneak
> >
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/99896e4fcd832c0003bb5e23ffd1a72837ea49bd.camel%40kortschak.io
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1RfkK%2B-4kKXUYSYiOve1Kq57ZNxAnOdGh7jbuDdUsKYA%40mail.gmail.com.

Re: [go-nuts] Re: Command line tool to modify YAML files

[Tyler Compton]

>
> I saw yq but it seemed like it was written in python, which I have no time
> for.
>

You're going to be limiting your tooling options quite a bit in that case
:)

On Mon, Nov 2, 2020 at 8:49 AM alex breadman  wrote:

> Thanks for the reply.
>
> I just did it for fun actually, and for the purpose of learning to make
> GitHub actions.
>
> I saw yq but it seemed like it was written in python, which I have no time
> for.
>
> The dasel one looks the best imo.
>
>
>
> On Mon, 2 Nov 2020, 4:41 pm Howard C. Shaw III, 
> wrote:
>
>> If written because you needed experience and writing a program to perform
>> a task you need done is better for learning, then go you! But if you are
>> legitimately looking to solve a problem, you might want to throw a quick
>> search out first before implementing Yet Another X.
>>
>> For yamlfukr update file.yaml key value:
>> https://github.com/mikefarah/yq
>> yq w -i file.yaml key value
>>
>> yq also supports b.c.d.e key names to edit deeper values.
>>
>> https://github.com/TomWright/dasel
>>
>> dasel put string -f file.yaml -p yaml "key" value
>>
>> dasel also supports b.c.d.e key names to edit deeper values.
>>
>> https://github.com/grasmash/yaml-cli
>> yaml-cli update:value file.yml key value
>>
>> If you intend to keep developing yamlfukr
>> , you might want to examine
>> some of the alternatives, and if you find them unsuitable, add to your
>> documentation why you find them so, so that someone coming on your project
>> can see why they should consider going with your tool instead of one of the
>> alternatives.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/b1fb908a-94f7-4487-b76a-50153d87c868n%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANaetAYF5USeu6OQivATC7TjciZfuCszK_-Lhok8ZxDsiBmWAw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2sRa4FdeZzyVkfJxpyUSe8DAkrA3KFJdROop%2BSsdqKqA%40mail.gmail.com.

Re: [go-nuts] Go is easy to lean. But other languages are hard to forget

[Tyler Compton]

I wonder if mailing lists for all languages get posts like this :)
Working in Go is great, but every language has sharp corners. Language
design is a tricky balancing act of trade-offs, and I don't think Go or any
other language is above that.

On Sun, Oct 4, 2020 at 1:25 PM Amnon  wrote:

> Go is a beautifully simple language. It is easy to learn.
> Most programmers can learn to write working production code within a day.
>
> But learning Go is the easy thing. It is much much harder to liberate
> yourself
> from the conceptual baggage that you have inherited from languages in your
> past.
> Every programmer carries scars from the sharp corners of previous
> languages,
> and these scars continue to infect the code they write today.
> It takes many months of immersion in idiomatic Go for these scars to have
> a chance to heal. Sometimes years. And some programmers never manage
> to escape the traumas and convoluted rituals of the past. And they are
> doomed to continue
> writing their former language in Go syntax, for the rest of their careers.
>
> So learning Go is easy. But exorcising the ghosts of former languages
> can be very very hard.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/efbfba1d-5d1e-47ed-8a16-c73c98ba1575n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3_FqC-dts%3Dq7RYFhxo7vMnfMoCvNJmhA968%3DWWA0oeew%40mail.gmail.com.

Re: [go-nuts] [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

[Tyler Compton]

Thanks Jan, this is very exciting! I'm looking forward to an opportunity to
use this.

On Wed, Aug 26, 2020 at 2:51 PM Jan Mercl <0xj...@gmail.com> wrote:

> From the change log (https://godoc.org/modernc.org/sqlite#hdr-Changelog)
>
> 2020-08-26 v1.4.0:
>
> First stable release for linux/amd64. The database/sql driver and its
> tests are CGo free. Tests of the translated sqlite3.c library still require
> CGo.
>
> $ make full
>
> ...
>
> SQLite 2020-08-14 13:23:32
> fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
> 0 errors out of 928271 tests on 3900x Linux 64-bit little-endian
> WARNING: Multi-threaded tests skipped: Linked against a non-threadsafe Tcl
> build
> All memory allocations freed - no leaks
> Maximum memory usage: 9156360 bytes
> Current memory usage: 0 bytes
> Number of malloc()  : -1 calls
> --- PASS: TestTclTest (1785.04s)
> PASS
> ok  modernc.org/sqlite  1785.041s
> $
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-XnjDzZnc31UOBn-gHoueT10FrvLCyZh9c8VK7K8ObKjg%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2rU1BNhu3suy5Jum0LQzEb2tKx%2BXgg_tdY6rA5vnTC1A%40mail.gmail.com.

Re: [go-nuts] A few thoughts on type parameters

[Tyler Compton]

On Wed, Aug 5, 2020 at 1:07 AM Jan Mercl <0xj...@gmail.com> wrote:

> It's not supposed to be anything special whatsoever. Just like number
> zero or an empty set is not some kind of an exception. It's just you
> cannot have any reasonable set theory without it.
>

I think it's fair to say that `interface{}` is somewhat special in practice
because it acts as an escape hatch from the type system when necessary. No
other interface is capable of being satisfied by values of all types. I
assume that the `error` interface is pre-declared because it's a very
common interface used across almost all Go code. If `interface{}` is to
become even more common than it is thanks to generics, I think it could be
reasonable to follow the same thinking.

Go programmers do avoid casting because Go has no casting. That word
> or its stem doesn't even appear in the language specs.
>

Something tells me you knew Carla was referring to type assertions.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0c-BqTt6vOjbE9ezur0nNNFCSBhgs%3DPFrEUBPASziinw%40mail.gmail.com.

Re: [go-nuts] Calling methods from inside a function in same package

[Tyler Compton]

I think I'm very likely misunderstanding your question. Would you mind
providing more detail?

You can definitely call methods within a function, even if they're defined
in the same package. In this example, I call a method from the type "myInt"
in the main function: https://play.golang.org/p/AAjVZCncUFJ


On Tue, Jul 21, 2020 at 9:51 AM Rudra  wrote:

> Hi,
> One can call global function of same package from inside a function, But I
> am curious if I can call a method from inside a function?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/cc1869a9-d6a2-4a2f-890d-d728439fa4c0n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0V2BMnfBS6TAus2yk4XKob2d9WCH8qiJ3y-8bZis-8Zw%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[Tyler Compton]

I had forgotten about the multidimensional slices proposal. That's a very
good counter-example.

On Sun, Jul 19, 2020 at 4:12 AM Ian Davis  wrote:

> On Sun, 19 Jul 2020, at 2:08 AM, Ian Lance Taylor wrote:
> > On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton 
> wrote:
> > >
> > > I'm beginning to think that community members (like myself) can't
> reasonably be expected to put in the necessary effort to champion a sizable
> language change. I think it was Ian who made multiple generics draft
> proposals just to reject them himself, then Ian and Robert Griesemer spent
> more untold hours writing the contracts draft design only to have that
> rejected as well. For people outside the core Go team, these probably would
> have been unpaid hours. It's hard to justify spending that kind of time
> when there's such a high chance that the proposal may not amount to
> anything. I think it's for this reason that community proposals are usually
> nowhere near as fleshed out as the draft proposals we've been getting from
> the core team.
> >
> > In fairness, though, there is no language change proposal that is as
> > large as generics.  The changes that were made in recent releases were
> > much smaller.  (And, for what it's worth, they did not all come from
> > Googlers; e.g., https://golang.org/issue/12711,
> > https://golang.org/issue/19308, https://golang.org/issue/29008.)
> >
>
> I think the multidimensional slices proposal (
> https://github.com/golang/go/issues/6282 and several spawned from there)
> is an example of a major proposed change that the community put great
> effort into with multiple detailed specifications. There is an asymmetry of
> time and expertise at play here. I suspect many people would use and
> benefit from native matrices in Go but the number of people with the
> necessary skills to design the spec and the amount of available time to
> devote to it is vanishingly small.
>
> We need a way for knowledgable experts to be able to take a sabbatical or
> similar to spend time refining and guiding their proposal with the Go team.
> Is this something that the Go project or another corporate sponsor could
> help with?
>
> Ian
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/37ed3f4e-460f-48b6-a636-61d3eadc5c8a%40www.fastmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3J%3Dfg9WxCfODoJ7NUagXfqm8e7SkgFVNNSOkAFd4Bazg%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[Tyler Compton]

I'm beginning to think that community members (like myself) can't
reasonably be expected to put in the necessary effort to champion a sizable
language change. I think it was Ian who made multiple generics draft
proposals just to reject them himself, then Ian and Robert Griesemer spent
more untold hours writing the contracts draft design only to have that
rejected as well. For people outside the core Go team, these probably would
have been unpaid hours. It's hard to justify spending that kind of time
when there's such a high chance that the proposal may not amount to
anything. I think it's for this reason that community proposals are usually
nowhere near as fleshed out as the draft proposals we've been getting from
the core team.

There are some incredibly talented and persistent gophers out there and I
don't mean to discourage them. This is just my observation from the
community proposals I've read.

On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:

> I have just read
> https://github.com/golang/go/issues/33892#issuecomment-659618902 and
> since it was posted on a closed issue I wanted to comment a bit more.
>
> I subscribed to this issue and read the updates for both the Go2 proposals
> as well as the Go1 proposals and I enjoy reading them.  I understand the
> reasoning behind wanting to do less here but I do belive there are some
> downsides as well.
>
> One reason I read these every week is that it gives people outside of the
> Go team an insight into the thought process and the reasoning of
> decisions.  Also feedback on these changes hopefully should help to refine
> future requests.  I am really afraid that just "ignoring" requests
> continues or goes back to the idea that  that Go is not a community
> language and that the only ideas and changes can come from Google employees
> (or past employees in the case of bradfitz).  The transparency here was
> awesome and I am very sad to see it go away.
>
> I hope there is some other middle ground or at least some details around
> what will go into hand picking?  For the non-picked proposals will they
> just remain open for some undetermined amount of time?  Will they just be
> closed?  Is feedback on these still expected?   Maybe the real solution is
> just to meet up less?  Maybe once a month or even once a quarter vs every
> week?
>
> Thank you,
>
> Brandon
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6e012c05-24ce-49cf-a8f2-b8b6f3f543ffo%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1KjOU0tzp_nWpV1a_qcFF3XNXs5AB4gsavhtHHPzmz9w%40mail.gmail.com.

Re: [go-nuts] the go archive size must be smaller？

[Tyler Compton]

I think something unfortunate happened to your diagram. On Gmail, I see an
 tag with a huge amount of base64 encoded text, and on Google Groups I
don't see anything at all. It may work better to upload the image to a
hosting service like Imgur and link to it.

On Thu, Jul 16, 2020 at 9:47 AM yangw...@gmail.com 
wrote:

> This diagram is the archive size of the go release package.
>
> What's this in those increase package size ?
> Maybe we can reduce the archive size in future.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e59710cd-aa23-483a-a8ad-2c8d8e9e9eaan%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3szRezYB51TB90eAhsHENWeZ_5ymEFBzX-z3D1d5mqbA%40mail.gmail.com.

Re: [go-nuts] [generics] Syntax feedback

[Tyler Compton]

Hi Andrey,

Unfortunately, I don't believe I can edit mailing list posts even on the
Google Groups page. Sorry to have missed your post originally!

On Sun, Jun 28, 2020 at 1:09 PM Andrey T. 
wrote:

> Tyler,
> May I humbly suggest
> https://groups.google.com/d/msg/golang-nuts/W3fSnH0w1G0/JbMkJrKICAAJ for
> an additional item for your list?
>
> Thank you very much,
>   Andrey
>
> On Saturday, June 27, 2020 at 11:46:23 AM UTC-6, Tyler Compton wrote:
>>
>> Hi Rob,
>>
>> This topic has been discussed many times on this list, so it's probably
>> best to look at and post in one of those threads. Let me take this chance
>> to collect as much information about this issue as I can in a single post.
>> Unfortunately, discoverability can sometimes be hard on mailing lists so
>> I don't blame you for not seeing all these.
>>
>> Responses on the subject:
>> Design draft talking about alternative syntax:
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
>> Ian's justification for taking a wait-and-see approach to this syntax
>> issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q
>>
>> Threads:
>> Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
>> Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
>> Use "::" and other suggestions:
>> https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
>> Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
>> Use "<>" before the name of the type being defined:
>> https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
>> Put type parameters in the regular arguments list with a ":type" suffix:
>> https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
>> Use "<>", with some kind of additional syntax to make parsing easier:
>> https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
>> Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
>> Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
>> Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
>> No specific suggestion:
>> https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/32da9686-d144-4d35-924f-b2bb1de7d9b3o%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/32da9686-d144-4d35-924f-b2bb1de7d9b3o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2-F-TCVQs%2Boskgz54pN6noXTkdtnzZt3r7Aezwe-oBOw%40mail.gmail.com.

Re: [go-nuts] [generics] Syntax feedback

[Tyler Compton]

Hi Rob,

This topic has been discussed many times on this list, so it's probably
best to look at and post in one of those threads. Let me take this chance
to collect as much information about this issue as I can in a single post.
Unfortunately, discoverability can sometimes be hard on mailing lists so I
don't blame you for not seeing all these.

Responses on the subject:
Design draft talking about alternative syntax:
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
Ian's justification for taking a wait-and-see approach to this syntax
issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q

Threads:
Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
Use "::" and other suggestions:
https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
Use "<>" before the name of the type being defined:
https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
Put type parameters in the regular arguments list with a ":type" suffix:
https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
Use "<>", with some kind of additional syntax to make parsing easier:
https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
No specific suggestion:
https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8


On Sat, Jun 27, 2020, 05:38 Rob Reid  wrote:

> Hi team,
>
> I wanted to provide some feedback on the syntax used in the generics
> proposal.
>
> When I first opened the Go 2 playground, it took me a while to realise
> that (type T) was a generic parameter and not a function parameter and that
> (s []T) was a function parameter and not a return parameter):
>
> func Print*(type T)(s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
> I think this would start to look more confusing when there are return
> values (either single or multiple):
>
> func Something*(type T)(s []T) (T, T)*
>
> I think another character would server to improve the readability of the
> Print function in this example and hopefully prevent the time required to
> grok a generic function to someone who has not seen one in Go before:
>
> func Print*(s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
> func Print*[type T](s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
>
> Cheers,
>
> Rob
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2Bcy9cUuJqOWWwi4m-MSp6gxKLGC4oFNn6y1zYJgN0Aac31sFg%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2VxFv9DeBhpX1F6urHHTQLxka82P4JAZuQWuRQCsDfRA%40mail.gmail.com.

Re: [go-nuts] Slices and inconsistency

[Tyler Compton]

On Fri, Jun 26, 2020 at 10:52 AM David Riley  wrote:

> Also, to this specific point: this exact approach, as with much of Go,
> embodies the Bell Labs approach to design (for better or for worse, and
> with good reason).  Sometimes we have to live with the artifacts of
> evolution.
>

One interesting counterexample here is the GC and scheduler, which take on
a huge amount of complexity in the implementation to create a dead-simple
interface. It seems like Go is willing to take a worse-is-better approach
when the amount of interface complexity is relatively small.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3xWV94g5smX%3D6kk3QD9fzZN_nhwqF0XykVsmUBDKLTLw%40mail.gmail.com.

Re: [go-nuts] How I can translate this shell command to golang code?

[Tyler Compton]

I just want to highlight an easy mistake to make here. One might expect to
be able to run something like this:

exec.Command("echo", "-n", "123456", "|", "dmtxwrite", "-s", "16x48", "-o",
"image.png")

But, as you might have found, this doesn't work. This is because the pipe
"|" is an operator implemented by shells like sh and bash. As mentioned in
the overview of the os/exec package, the package never invokes your shell
automatically, so operators like the pipe operator are not available by
default. Jan's answer works because it invokes the shell explicitly to run
your command.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0YtHNT01vV1JxvpaORfaBCNMLdSYz2LBVpZZHXwNBt3Q%40mail.gmail.com.

Re: [go-nuts] Re: [generics] I think it's better have higher perfomance than lower compiling time

[Tyler Compton]

The idea of having development and release compilation modes sounds
appealing at first, though I'm a bit skeptical about how it would turn out.
This would mean that, during development, you wouldn't have a full
understanding of the performance characteristics of your program.
Admittedly, that's not something you *always* care about, but when you do
care you'll have to deal with slow compilation times.

I've found that in C++ certain memory safety bugs will only rear their ugly
head after a certain compiler optimization level, meaning that these bugs
can be missed during development. Go's memory safety would probably make
this significantly less of a problem, but it still concerns me somewhat.

On Fri, Jun 19, 2020 at 6:46 PM David Skinner 
wrote:

> I remember going on a two-hour lunch break at a Cajun restaurant and
> returning to my office to discover that my precompiled C++ headers were
> still compiling. I really love that Go compiles quickly and links quickly.
>
> The day comes when code needs to ship, final compile, and final quality
> control tests,  why not have a final build that compiles quite slowly and
> optimizes to the max. There is no need to do either/or and compromise, just
> do both.
>
> On Friday, June 19, 2020 at 12:23:46 PM UTC-5, Ronald Davilla wrote:
>>
>> Just if perfomance will decrease with every release/version, it'd be not
>> really good, and it's might be necessary to pay more attention to this
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/fd72210d-5a04-4be3-b51c-50b8313bf3dao%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1mBzN6YJJLtAOb1ZBPuDgXoCDzuG34x5XGPwTk1u-q8A%40mail.gmail.com.

Re: [go-nuts] Go has confusing pointers

[Tyler Compton]

>
> c is of type *Count (pointer to Count), surely?
>

Yes, my mistake! Thank you for the correction.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3e__kHGcgeAHzZ25jHW1rODpmj_p71yuGeef_yjXeC5g%40mail.gmail.com.

Re: [go-nuts] Go has confusing pointers

[Tyler Compton]

>
>  *c = *c + 1 //why use *c and not just c, based on (c *Count) c is already
> a pointer?
>

In Go (as well as other languages like C) '*' plays two roles. When used
with a type like in "c *Count", it tells you that c is a pointer to a Count
object. When used on a variable, like "*c + 1", it dereferences the
pointer. In other words, "*c + 1" gets the value that "c" is pointing to
and adds one to that value.


> why cast to int, c is already of type int?
>

In this case, c is of type Count, not int. When you define a type in Go,
you're defining a new distinct type, not an alias to the underlying type.
The Count type is distinct from int, even though it's based on int.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2GL8oLmpjLcoVh8uJu8m4GFJdSh7SfhbvFy%3D9%2BtVwQDQ%40mail.gmail.com.

Re: [go-nuts] [generics] Simplification: Methods refer to original type parameters instead of re-specifying each time

[Tyler Compton]

I think this syntax could get confusing when embedded fields is added to
the mix:

type MyStruct(type T) struct {
T
}

func (ms *MyStruct) MyMethod(t ms.T) {
ms.T =  t
}

In this example. ms.T means two very different things depending on where
they are used.

On Wed, Jun 17, 2020 at 3:45 AM Randall O'Reilly 
wrote:

> You could save a fair amount of typing and eyestrain by not replicating
> the type params for types, in their methods:
>
> type Vector(type T) []T
>
> func (v *Vector) Push(x v.T) { *v = append(*v, x) }
>
> 
>
> type Map(type K, V) struct {
> root*node(K, V)
> compare func(K, K) int
> }
>
> func (m *Map) InOrder() *Iterator(m.K, m.V) {
> type kv = keyValue(m.K, m.V) // convenient shorthand
> sender, receiver := chans.Ranger(kv)()
> var f func(*node(m.K, m.V)) bool
> ...
> }
>
> Could also just have the bare type param name without the field-like
> specifier (e.g., K, V instead of m.K, m.V) but that makes it less obvious
> what K and V are -- m.K makes it clear that K is something I can find if I
> look at the definition of the type of m.
>
> This also enforces consistent naming of type parameters across all methods.
>
> - Randy
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2605713E-73F3-4332-911D-D41EAE4DAF6A%40gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0YzwH8XYM-QOqbnm3YC_WA8Jce_jnzOS4YhP41FjwTKw%40mail.gmail.com.

Re: [go-nuts] [generics] is generics with constrain needed ?

[Tyler Compton]

The reason why implicit conversions from []Foo to []Stringer isn't
supported is because Foo and Stringer have different in-memory
representations. Converting from a slice of one to a slice of another would
be more expensive than one would expect an implicit conversion to be. At
least, this is my understanding as to why.

On Wed, Jun 17, 2020 at 3:22 AM Miguel Angel Rivera Notararigo <
ntr...@gmail.com> wrote:

> Allowing this implicit conversion would be a bad thing? because it works
> like generics without any new syntax.
>
> Also, I found this a little messy
>
> type Ordered interface {
>   type int, int8, int16, int32, int64,
>   uint, uint8, uint16, uint32, uint64, uintptr,
>   float32, float64,
>   string}
>
>
> Why not after interface?
>
> type Ordered interface type {
>   int, int8, int16, int32, int64,
>   uint, uint8, uint16, uint32, uint64,
>   byte, rune, uintptr,
>   float32, float64,
>   string,}
>
>
> Sorry, I am pretty new to this, so probably the answers might be really
> obvious 😅
>
> On Wed, Jun 17, 2020 at 4:37 AM David Anderson  wrote:
>
>> The non-generic form _only_ accepts an argument of type []Stringer. If
>> you have a []Foo, where Foo implements Stringer, that's not good enough.
>> You will have to construct a []Stringer explicitly, and copy each Foo into
>> that []Stringer. This is a fairly common gotcha with Go, where folks expect
>> the implicit conversion to happen.
>>
>> OTOH, the generic form will accept []Foo directly, since Foo satisfies
>> the Stringer constraint.
>>
>> - Dave
>>
>> On Wed, Jun 17, 2020 at 1:20 AM Christophe Meessen <
>> christophe.mees...@gmail.com> wrote:
>>
>>> Reading the document "Type parameters - Draft desing" of June 16, 2020 (
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md),
>>> I wonder if these two following function definitions are not equivalent and
>>> thus interchangeable
>>>
>>> func Stringify(type T Stringer)(s []T) (ret []string)
>>>
>>> func Stringify(s []Stringer) (ret []string)
>>>
>>> If the constrain is an interface, wouldn’t it be the same as to use the 
>>> interface as type ? How would it be different ?
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/3b758827-2d14-4769-bf94-95cf60a06b1bo%40googlegroups.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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAMx%2Br7Vc9pLY63qJg1ek4ZrYq8YMyJFOLwzN5aLA6T8nho16Ww%40mail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAF9DLCm%3D0DSjRk2quhh%3D3L_eUH9%2BuxPXp6-8mzh%3DjZ0csy9rwQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1_0stPaP0U%3Dv91%3DWcyvRiWO0Pg12cKmbFYbapq%2BKir2w%40mail.gmail.com.

Re: [go-nuts] randomly go loading modules fail

[Tyler Compton]

I saw some discussion in a previous thread indicating that Gitlab is having
an incident. More details here:
https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7

On Fri, May 15, 2020 at 10:04 AM msherif4 via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi :
>
>  I have seen randomly go dependancies fail to load certain modules
> like the case below
>
> [0m [91mgo: modernc.org/mathutil@v1.0.0: git fetch -f origin 
> refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
> /go/pkg/mod/cache/vcs/fb72eb2422fda47ac75ca695d44b06b82f3df3c5308e271486fca5e320879130:
>  exit status 128:
>   fatal: unable to access 'https://gitlab.com/cznic/mathutil/': The 
> requested URL returned error: 502
>
>
> [0m [91mgo: modernc.org/xc@v1.0.0: git fetch -f origin 
> refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
> /go/pkg/mod/cache/vcs/29fc2f846f24ce3630fdd4abfc664927c4ad22f98a3589050facafa0991faada:
>  exit status 128:
>   fatal: unable to access 'https://gitlab.com/cznic/xc/': The requested 
> URL returned error: 502
> go: error loading module requirements
>
>
> again this happens randomly not consistent
>
>
> anyone run into the same and is there anyway to fix it ?
>
>
> Thanks!!
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5e12cce1-dcee-4276-97af-daf4bec9e111%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3sfkRUkCnvw84vb-FXU%2BupRBDsEmcQzJnLuoWBNfd8-Q%40mail.gmail.com.

Re: [go-nuts] Re: What are finalizers missing?

[Tyler Compton]

Good point, I had forgotten about the 2 minute rule the GC has.

So it's not a matter of  the go runtime not knowing "which Go objects it
> can finalize in order to get that [a resource] back", its simply a matter
> of the variable pace of GC. In theory GC can happen as infrequently as
> every 2 minutes. So if you are ok with you non-Go resource lingering for
> that long, then use finalizers. In most cases that is not sufficient though.
>

I think you're touching on the point I'm trying to make. The variable pace
of the GC is okay for Go memory, because it can adjust that pace if
necessary to keep up with garbage production. The GC can't make pace
adjustments based on the consumption of any non-Go-memory resources, which
means we can only count on a maximum of 2 minutes between GC runs.

I could certainly see situations where there's no way the GC could make a
smart enough decision to fit an application's needs, however. For example,
if your program writes to a file that another program then uses, you would
want to make sure that the file is closed before that other program is spun
up. Even a 1 second GC delay might not work here.

On Sat, Feb 15, 2020 at 10:52 AM Jake Montgomery  wrote:

> On Friday, February 14, 2020 at 2:10:01 PM UTC-5, Tyler Compton wrote:
>>
>> The conventional wisdom I see in the Go community is to avoid using
>> finalizers to manage file descriptors, C memory, or any other non-Go memory
>> resource. The generally accepted rationale (at least to my understanding)
>> is that the garbage collector cannot be expected to run the finalizer
>> promptly, and it may never be run at all.
>>
>>
>
>> This is where I start speculating. I assume this is because the garbage
>> collector has no understanding of C memory, file descriptors, or any other
>> kind of resource. If we're running out of memory due to a malloc in C,
>> there's no way for the garbage collector to know which Go objects it can
>> finalize in order to get that memory back.
>>
>
> I don't think your analysis is correct. IIRC, the spec makes no guarantees
> about finalizers ever actually being run. But in practice they will all be
> found and run after the first garbage collection after the object becomes
> unreachable. (Assuming the app continues to run.) So it's not a matter of
> the go runtime not knowing "which Go objects it can finalize in order to
> get that [a resource] back", its simply a matter of the variable pace of
> GC. In theory GC can happen as infrequently as every 2 minutes. So if you
> are ok with you non-Go resource lingering for that long, then use
> finalizers. In most cases that is not sufficient though.
>
> One other, minor, consideration, is also that setting a finalizer will
> cause the object to escape to the heap.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9d2fd31b-f283-4dec-bb38-8cc8cc844249%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/9d2fd31b-f283-4dec-bb38-8cc8cc844249%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1OF_tBMKXgJKCFU9U_SNvdiKTvg1c%2B9-4KFL7e5jo5bA%40mail.gmail.com.

[go-nuts] Re: What are finalizers missing?

[Tyler Compton]

I found a relevant blog post by David Crawshaw that touches on the topic of
a garbage collector that can be extended to understand resources other than
Go-managed memory: https://crawshaw.io/blog/tragedy-of-finalizers

On Fri, Feb 14, 2020 at 11:09 AM Tyler Compton  wrote:

> The conventional wisdom I see in the Go community is to avoid using
> finalizers to manage file descriptors, C memory, or any other non-Go memory
> resource. The generally accepted rationale (at least to my understanding)
> is that the garbage collector cannot be expected to run the finalizer
> promptly, and it may never be run at all.
>
> This is where I start speculating. I assume this is because the garbage
> collector has no understanding of C memory, file descriptors, or any other
> kind of resource. If we're running out of memory due to a malloc in C,
> there's no way for the garbage collector to know which Go objects it can
> finalize in order to get that memory back. However, as a thought
> experiment, if we were able to tell the garbage collector (say, through a
> function in the runtime package) that a certain Go object owns X number of
> file descriptors or X bytes of C memory, could the garbage collector be
> augmented to free these objects (and thus run their finalizers)
> intelligently? Would doing so allow us to use finalizers for these
> resources with confidence?
>
> I don't mean this to be a proposal or suggestion. I'm asking more as an
> opportunity to learn.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2RULyyHRn35t7YUJ%3DtWcRYmEYUWD%2Bmy8R_aqnD1%2B7OiQ%40mail.gmail.com.

Re: [go-nuts] What are finalizers missing?

[Tyler Compton]

Thanks for the pointer! I took a look at PhantomReferences and Cleaners,
and I see how they could be a more robust way to free resources for an
object. However, I don't see a mechanism by which they can express to the
garbage collector how much "pressure" they exert on a finite resource (file
descriptors, memory not managed by the Java GC, etc). I don't know very
much about the Java GC, but in a scenario where we have a few Java objects
with a low amount of memory usage but with a large number of (for example)
file descriptors, the Java GC might just decide not to run because it has
no knowledge of the fact that running would help free up file descriptors.

In other words, I see how PhantomReferences and Cleaners are less brittle
than runtime.SetFinalizer, but not how they're more capable of managing
resources that the GC is not already aware of.

On Fri, Feb 14, 2020 at 11:17 AM Robert Engels 
wrote:

>
> I suggest you look at PhantomReference in Java, and the Cleaner/Disposer
> classes/patterns for how this would work. Go doesn't have
> PhantomReferences, so it's moot at this time.
>
> -Original Message-
> From: Tyler Compton
> Sent: Feb 14, 2020 1:09 PM
> To: golang-nuts
> Subject: [go-nuts] What are finalizers missing?
>
> The conventional wisdom I see in the Go community is to avoid using
> finalizers to manage file descriptors, C memory, or any other non-Go memory
> resource. The generally accepted rationale (at least to my understanding)
> is that the garbage collector cannot be expected to run the finalizer
> promptly, and it may never be run at all.
>
> This is where I start speculating. I assume this is because the garbage
> collector has no understanding of C memory, file descriptors, or any other
> kind of resource. If we're running out of memory due to a malloc in C,
> there's no way for the garbage collector to know which Go objects it can
> finalize in order to get that memory back. However, as a thought
> experiment, if we were able to tell the garbage collector (say, through a
> function in the runtime package) that a certain Go object owns X number of
> file descriptors or X bytes of C memory, could the garbage collector be
> augmented to free these objects (and thus run their finalizers)
> intelligently? Would doing so allow us to use finalizers for these
> resources with confidence?
>
> I don't mean this to be a proposal or suggestion. I'm asking more as an
> opportunity to learn.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3xrghcLhrj3La1niVnHs07DdCUUDfWjpVTyTUkhMwTjA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3xrghcLhrj3La1niVnHs07DdCUUDfWjpVTyTUkhMwTjA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0%2B5zLVZOW6RrMLcBEKJ0KEVRsdBvDKEP96mavD0hHxUQ%40mail.gmail.com.

[go-nuts] What are finalizers missing?

[Tyler Compton]

The conventional wisdom I see in the Go community is to avoid using
finalizers to manage file descriptors, C memory, or any other non-Go memory
resource. The generally accepted rationale (at least to my understanding)
is that the garbage collector cannot be expected to run the finalizer
promptly, and it may never be run at all.

This is where I start speculating. I assume this is because the garbage
collector has no understanding of C memory, file descriptors, or any other
kind of resource. If we're running out of memory due to a malloc in C,
there's no way for the garbage collector to know which Go objects it can
finalize in order to get that memory back. However, as a thought
experiment, if we were able to tell the garbage collector (say, through a
function in the runtime package) that a certain Go object owns X number of
file descriptors or X bytes of C memory, could the garbage collector be
augmented to free these objects (and thus run their finalizers)
intelligently? Would doing so allow us to use finalizers for these
resources with confidence?

I don't mean this to be a proposal or suggestion. I'm asking more as an
opportunity to learn.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3xrghcLhrj3La1niVnHs07DdCUUDfWjpVTyTUkhMwTjA%40mail.gmail.com.

Re: [go-nuts] Why Discord is switching from Go to Rust

[Tyler Compton]

It would have been nice to see performance measurements from a more recent
Go version. That said, it makes sense to me that Rust would be a better
choice for this kind of application, where the main performance bottleneck
is the sheer number of objects in memory. A language where you get to
express more about the life-cycle of these objects should perform better. I
say this as someone that knows very little about Rust, so I'm probably
greatly oversimplifying.

On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
wrote:

> I think Go is way better than Rust, but it is amusing to see why people
> pick one over another.
>
> "Remarkably, we had only put very basic thought into optimization as the
> Rust version was written. Even with just basic optimization, Rust was able
> to outperform the hyper hand-tuned Go version. This is a huge testament to
> how easy it is to write efficient programs with Rust compared to the deep
> dive we had to do with Go."
>
>
> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com.

Re: [go-nuts] Re: go1.12.16 not tagged on release-branch.go1.12?

[Tyler Compton]

I think it's very reasonable to ask a simple Git workflow question on
golang-nuts without having to provide reproduction steps.

Yes, I posted the error in reproducible form. The first step in fixing a
> bug. The Go team can confirm the bug and verify that their fix works. No
> guesswork required.


I think you're unintentionally coming off as condescending.

On Wed, Jan 29, 2020 at 5:31 AM peterGo  wrote:

> Steve,
>
> "I don't see"
>
> Please provide reproducible errors. For example,
>
> [security] Go 1.13.7 and Go 1.12.16 are released
> https://groups.google.com/forum/#!topic/golang-nuts/4uVpv5Zfxvo
>
> ~$ git clone https://github.com/golang/go --depth 1 -b
> release-branch.go1.12 go1.12
> Cloning into 'go1.12'...
> remote: Enumerating objects: 9305, done.
> remote: Counting objects: 100% (9305/9305), done.
> remote: Compressing objects: 100% (7682/7682), done.
> remote: Total 9305 (delta 1465), reused 4643 (delta 1134), pack-reused 0
> Receiving objects: 100% (9305/9305), 21.22 MiB | 11.94 MiB/s, done.
> Resolving deltas: 100% (1465/1465), done.
> ~$ cd go1.12/src
> ~/go1.12/src$ ./make.bash
> Building Go cmd/dist using /home/peter/go1.4.
> Building Go toolchain1 using /home/peter/go1.4.
> Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
> Building Go toolchain2 using go_bootstrap and Go toolchain1.
> Building Go toolchain3 using go_bootstrap and Go toolchain2.
> Building packages and commands for linux/amd64.
> ---
> Installed Go for linux/amd64 in /home/peter/go1.12
> Installed commands in /home/peter/go1.12/bin
> ~/go1.12/src$ cd ../bin
> ~/go1.12/bin$ ./go version
> go version go1.12.15 linux/amd64
> ~/go1.12/bin$
>
> Peter
>
> On Wednesday, January 29, 2020 at 6:30:23 AM UTC-5, Steve Mynott wrote:
>>
>> I don't see go1.12.16 tagged on release-branch.go1.12?
>>
>> Is this expected?
>>
>> --
>> Steve Mynott 
>> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3522d571-43da-48c3-8158-286ce7c4b092%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0wkWH2tc5_97FQoHHu%3DZC4E0CATM5u%2BnF0VQv3fxeEwA%40mail.gmail.com.

Re: [go-nuts] Golang and EOL of Windows 7 (Windows Server 2008)

[Tyler Compton]

As a data point, Go stopped supporting Windows XP in Go 1.10. That's 4
years after Microsoft officially ended support for the operating system. I
don't think that's a hard rule, and it will probably depend on what version
Go's main Windows contributors use.

Relevant issue: https://golang.org/issues/23380

On Mon, Nov 18, 2019 at 10:12 AM 'Pier-Hugues Pellerin' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
> Hello everyone,
>
> I've been trying to find information about how the Go team deals with EOL
> of a specific platform.
> I am working on products that currently support Windows 7 and were users
> will not move quickly out of the
> platform.
>
> Since the EOL of Windows 7 (and Windows Server 2008) is scheduled for
> January 14, 2020,  I would like to know if there is any
> plan to remove that platform and if so is there a target version for that
> removal?
>
> I've looked at the Github tracker, but I haven't found anything related to
> that.
>
> Thanks
>
> PH
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c10234c5-943b-4061-85c9-a5cf06202372%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2a1fY8tsjqPN7rPfRpv_Zh3q2mKqJFQKQig9uuPYma9A%40mail.gmail.com.

[go-nuts] Re: [golang-dev] go.dev is live!

[Tyler Compton]

Thanks for posting! I'm really impressed the website, and with the package
view especially. I foresee myself using this instead of godoc.org from now
on.

I'm curious to hear more about the team's future plans for golang.org. Do
you have any plans to migrate or mirror content like the blog or the
download links over time? I could see some minor confusion popping up
regarding which website to go to for which task, though I see this has been
partially addressed by adding links to many of golang.org's resources on
go.dev, which is thoughtful.

On Wed, Nov 13, 2019, 09:15 'Julie Qiu' via golang-dev <
golang-...@googlegroups.com> wrote:

> Hey Gophers,
>
> We are excited to share that go.dev, a new hub for Go developers, is now
> live!
>
> At go.dev, you will find information on how to get started with the
> language, featured use cases, and other resources. It is a companion site
> to golang.org. You can read about it on the latest Go blog post
> .
>
> You will also find a new place to discover Go packages and modules,
> pkg.go.dev, by clicking on Explore in the header or footer.
>
> Pkg.go.dev  serves Go documentation like godoc.org,
> but it also understands modules and has information about previous versions
> of a package (such as all releases of the Go standard library
> !). It also detects and displays
> licenses and has a better search algorithm.
>
> You can follow Go issue 33654  for future
> developments on pkg.go.dev.
>
> We are just starting to build out go.dev, so some bugs are to be
> expected. We want to work with all of you to make this site better for Go
> developers, so please share your feedback with us and file issues if you
> spot them! You can do that by clicking "Share Feedback" or "Report an
> Issue" at the footer of every page, or by emailing
> go-discovery-feedb...@google.com. See go.dev/about for more information
> about the site.
>
> We hope you enjoy the new site and look forward to hearing your feedback!
>
> Warmly ☀️,
>
> Julie for the Go team
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/CAGJ2NqEcskx_492HFpV%3DUavMLgXoYmXaZ1ivigqnjfc-9U8wFA%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0AnuaU74-7dAriVk2JhUV3_850xGLLDfjnBodrq_-8QQ%40mail.gmail.com.

Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

[Tyler Compton]

That's a good point. Also, now that I think of it, with the help of a
profiler it should be straightforward to identify places where iterating
over a slice is a problem regardless of how the iteration is expressed. I'm
convinced!

On Tue, Nov 5, 2019 at 4:05 PM Robert Engels  wrote:

> I think that’s splitting hairs a bit. Even if you see the loop you don’t
> know the cost unless you know the size of a slice. For instance, a lookup
> in a small slice is actually cheaper than a small map - in memory and
> speed. So you need to know more than “it’s a slice” to make a judgement.
>
> On Nov 5, 2019, at 5:58 PM, Tyler Compton  wrote:
>
> 
> I agree with you that an original writer of the code should be expected to
> know that a theoretical "contains" or "in" expression has O(n) properties.
> However, I've always thought of this from the perspective of someone
> looking at the code later and trying to identify performance issues. It's
> easy to identify a potentially very costly iteration through a slice if
> it's more verbose and always expressed the same way.
>
> On Tue, Nov 5, 2019 at 2:44 PM Robert Engels 
> wrote:
>
>> Is it though?
>>
>> You would have the same problem if you thought the size of mySlice was
>> always small, and it wasn't - range could be quite expensive (or not) - and
>> if that was not valid workable you should be using something other than a
>> slice.
>>
>> You need understanding of the types and cost of operations in any
>> language, and the naming (or something else) should make the types easily
>> recognizable (and understandable).
>>
>>
>> -Original Message-
>> From: Tyler Compton
>> Sent: Nov 5, 2019 3:57 PM
>> To: toddsu...@icloud.com
>> Cc: golang-nuts
>> Subject: Re: [go-nuts] Why doesn't Go include a contains method for
>> things like slices?
>>
>> Ian's answer addresses your question about the absence of a
>> slice.Contains method, but there have been discussions in the past about
>> adding such a feature to the language itself as well. You brought up the
>> idea of a builtin "contains" function, and I've seen others suggest adding
>> something like Python's "in" operator as well. To most of these proposals,
>> the answer has been "no" because of concerns about hiding a potentially
>> very expensive operation behind a builtin or operator. There's no doubt
>> that:
>>
>> return myObj in mySlice
>>
>> ... is easier to miss than:
>>
>> for _, obj := range mySlice {
>> if obj == myObj {
>> return true
>> }
>> }
>> return false
>>
>> On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Sorry if this question reveals my newness to Go. I tried searching the
>>> mailing list but I couldn't find anything in a quick search. It seems like
>>> many languages include the ability to check if an array, or slice contain a
>>> particular value. I understand that you could do this easily with a for
>>> loop or alternatively use a map instead. However, is there a reason why Go
>>> doesn't just have slice.Contains(interface{}) or maybe a builtin
>>> contains(mySlice, interface{}) ?
>>>
>>> I assume one reason might be because slices could potentially be really
>>> large? Or maybe the community feels that a simple for loop is so easy that
>>> it is not necessary? I would love to understand this more.
>>>
>>> Thank You!
>>> -Todd
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3LVUjcz7jg%2BmUhGvbmhHL%2B6ycgh7zNouRx6_JwN-eDoQ%40mail.gmail.com.

Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

[Tyler Compton]

I should mention that I don't 100% buy this argument and I would still like
to see a "slices.Contains" function in the future if/when generics are
added. I'm trying (perhaps poorly) to explain what I've seen as the most
common argument against adding such a feature.

On Tue, Nov 5, 2019 at 3:58 PM Tyler Compton  wrote:

> I agree with you that an original writer of the code should be expected to
> know that a theoretical "contains" or "in" expression has O(n) properties.
> However, I've always thought of this from the perspective of someone
> looking at the code later and trying to identify performance issues. It's
> easy to identify a potentially very costly iteration through a slice if
> it's more verbose and always expressed the same way.
>
> On Tue, Nov 5, 2019 at 2:44 PM Robert Engels 
> wrote:
>
>> Is it though?
>>
>> You would have the same problem if you thought the size of mySlice was
>> always small, and it wasn't - range could be quite expensive (or not) - and
>> if that was not valid workable you should be using something other than a
>> slice.
>>
>> You need understanding of the types and cost of operations in any
>> language, and the naming (or something else) should make the types easily
>> recognizable (and understandable).
>>
>>
>> -Original Message-
>> From: Tyler Compton
>> Sent: Nov 5, 2019 3:57 PM
>> To: toddsu...@icloud.com
>> Cc: golang-nuts
>> Subject: Re: [go-nuts] Why doesn't Go include a contains method for
>> things like slices?
>>
>> Ian's answer addresses your question about the absence of a
>> slice.Contains method, but there have been discussions in the past about
>> adding such a feature to the language itself as well. You brought up the
>> idea of a builtin "contains" function, and I've seen others suggest adding
>> something like Python's "in" operator as well. To most of these proposals,
>> the answer has been "no" because of concerns about hiding a potentially
>> very expensive operation behind a builtin or operator. There's no doubt
>> that:
>>
>> return myObj in mySlice
>>
>> ... is easier to miss than:
>>
>> for _, obj := range mySlice {
>> if obj == myObj {
>> return true
>> }
>> }
>> return false
>>
>> On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Sorry if this question reveals my newness to Go. I tried searching the
>>> mailing list but I couldn't find anything in a quick search. It seems like
>>> many languages include the ability to check if an array, or slice contain a
>>> particular value. I understand that you could do this easily with a for
>>> loop or alternatively use a map instead. However, is there a reason why Go
>>> doesn't just have slice.Contains(interface{}) or maybe a builtin
>>> contains(mySlice, interface{}) ?
>>>
>>> I assume one reason might be because slices could potentially be really
>>> large? Or maybe the community feels that a simple for loop is so easy that
>>> it is not necessary? I would love to understand this more.
>>>
>>> Thank You!
>>> -Todd
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0nutbzRuStD7bfWFXu5v0mGJcOpoXyc4ZLK7bW67vtaw%40mail.gmail.com.

Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

[Tyler Compton]

I agree with you that an original writer of the code should be expected to
know that a theoretical "contains" or "in" expression has O(n) properties.
However, I've always thought of this from the perspective of someone
looking at the code later and trying to identify performance issues. It's
easy to identify a potentially very costly iteration through a slice if
it's more verbose and always expressed the same way.

On Tue, Nov 5, 2019 at 2:44 PM Robert Engels  wrote:

> Is it though?
>
> You would have the same problem if you thought the size of mySlice was
> always small, and it wasn't - range could be quite expensive (or not) - and
> if that was not valid workable you should be using something other than a
> slice.
>
> You need understanding of the types and cost of operations in any
> language, and the naming (or something else) should make the types easily
> recognizable (and understandable).
>
>
> -Original Message-
> From: Tyler Compton
> Sent: Nov 5, 2019 3:57 PM
> To: toddsu...@icloud.com
> Cc: golang-nuts
> Subject: Re: [go-nuts] Why doesn't Go include a contains method for things
> like slices?
>
> Ian's answer addresses your question about the absence of a slice.Contains
> method, but there have been discussions in the past about adding such a
> feature to the language itself as well. You brought up the idea of a
> builtin "contains" function, and I've seen others suggest adding something
> like Python's "in" operator as well. To most of these proposals, the answer
> has been "no" because of concerns about hiding a potentially very expensive
> operation behind a builtin or operator. There's no doubt that:
>
> return myObj in mySlice
>
> ... is easier to miss than:
>
> for _, obj := range mySlice {
> if obj == myObj {
> return true
> }
> }
> return false
>
> On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Sorry if this question reveals my newness to Go. I tried searching the
>> mailing list but I couldn't find anything in a quick search. It seems like
>> many languages include the ability to check if an array, or slice contain a
>> particular value. I understand that you could do this easily with a for
>> loop or alternatively use a map instead. However, is there a reason why Go
>> doesn't just have slice.Contains(interface{}) or maybe a builtin
>> contains(mySlice, interface{}) ?
>>
>> I assume one reason might be because slices could potentially be really
>> large? Or maybe the community feels that a simple for loop is so easy that
>> it is not necessary? I would love to understand this more.
>>
>> Thank You!
>> -Todd
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1icLW8yRRX6%2BW6XVmX8k6SpkUSKNSPnejtEMdgyidu4Q%40mail.gmail.com.

Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

[Tyler Compton]

Ian's answer addresses your question about the absence of a slice.Contains
method, but there have been discussions in the past about adding such a
feature to the language itself as well. You brought up the idea of a
builtin "contains" function, and I've seen others suggest adding something
like Python's "in" operator as well. To most of these proposals, the answer
has been "no" because of concerns about hiding a potentially very expensive
operation behind a builtin or operator. There's no doubt that:

return myObj in mySlice

... is easier to miss than:

for _, obj := range mySlice {
if obj == myObj {
return true
}
}
return false

On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Sorry if this question reveals my newness to Go. I tried searching the
> mailing list but I couldn't find anything in a quick search. It seems like
> many languages include the ability to check if an array, or slice contain a
> particular value. I understand that you could do this easily with a for
> loop or alternatively use a map instead. However, is there a reason why Go
> doesn't just have slice.Contains(interface{}) or maybe a builtin
> contains(mySlice, interface{}) ?
>
> I assume one reason might be because slices could potentially be really
> large? Or maybe the community feels that a simple for loop is so easy that
> it is not necessary? I would love to understand this more.
>
> Thank You!
> -Todd
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com.

Re: [go-nuts] using Go as a configuration file format

[Tyler Compton]

I do think that turing complete configuration have their place in very
limited circumstances. For example, I use a window manager called Awesome
WM that is configured with Lua, and that allows me to implement my own
features into the WM while configuring it. The significant disadvantage
here is that Awesome WM exposes a very large API surface to the
configuration file, making it very likely that your configuration will
break with a new release, and writing an automatic migration would be
significantly more difficult than if it were a configuration file.

It makes it impossible to implement a parser and evaluator for the format
> in a different language. Which should always be possible for a config file
> format.
>

This problem can be partially addressed by using a language like Lua that
has a very small C interpreter library and can be called from a variety of
languages, but I appreciate your point.


>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8Qi8JFA4WSCU7TLuXmgjx-WcAzJcuDdV08XSwz%2Bicziw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3%3DQgaWDXCc9MWxOaRkYYwYg7_Ka%2BpoNLYs8CjgK%2B0QMA%40mail.gmail.com.

Re: [go-nuts] How to do a forward compatibility support for go 1.13?

[Tyler Compton]

I think that in general you will have to only use features available to Go
1.11, meaning, of course, that the new methods in the errors package would
be off limits. In the mean time you could use golang.org/x/xerrors, which
is a superset of the new errors package and I believe will work with 1.11.

On Fri, Sep 6, 2019, 7:50 AM changkun  wrote:

> I have upgraded my code to Go 1.13 with newly introduced errors APIs.
>
> However, I am not able to upgrade the production environment Go version
> which is Go 1.11, which means I have to run Go 1.13 code on a Go 1.11
> environment.
>
> What are the way to make my builds both happy on local and production
> environment with a single code base?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0a915d38-39f4-4083-b730-75320a4eecc6%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1cXxzt7B4L%2B7sHw%3DxT-%2BA5J44n1PdtszQ%3DxTAoJOwU_g%40mail.gmail.com.

Re: [go-nuts] [ANN] sqlc: Generate type-safe Go from SQL

[Tyler Compton]

This is very cool! It's an interesting compromise between using a fully
featured ORM and interacting with SQL queries directly, and may be a good
sweet spot.

Have you considered supporting documentation in generated code? Maybe by
allowing for syntax like this for queries:

-- name: ListAuthors :many
--
-- ListAuthors retrieves all authors from the database blah blah.
SELECT * FROM authors
ORDER BY name;

... that would generate code like this:

// ListAuthors retrieves all authors from the database blah blah.
func (q *Queries) ListAuthors(ctx context.Context) ([]Author, error) {
...
}

I'm not too familiar with Postgres, but in MySQL you can create tables with
comments. It looks like there's a similar feature in Postgres.

CREATE TABLE authors (
id int,
name VARCHAR(255) COMMENT "The name of the author who wrote the book",
bio VARCHAR(512) COMMENT "A short description of the author"
) COMMENT "Author is the author of a piece of literature.";

It might be nice if those comments propagated to the struct definition
automatically.

// Author is the author of a piece of literature.
type Author struct {
ID   int64
// The name of the author who wrote the book
Name string
// A short description of the author
Bio  sql.NullString
}

On Tue, Sep 3, 2019 at 7:43 AM  wrote:

> Hey folks,
>
> I'd like to introduce sqlc[0], a tool that compiles SQL queries into
> type-safe, idiomatic Go. It also catches common errors in SQL such as
> mistyped column names and incorrect parameter numbering.
>
> If this sounds like something that would be useful to you, take a read
> through the Getting Started[1] guide.
>
> Cheers,
> Kyle
>
> [0] https://github.com/kyleconroy/sqlc
> [1]
> https://github.com/kyleconroy/sqlc/blob/master/README.md#getting-started
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/399e7595-1f79-4fc5-a6bd-498b312168d5%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1-ex8soB6yK76SqMJohSgE%2B%2BhiR4cvgB28mHiEVVYe%2BA%40mail.gmail.com.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Tyler Compton]

>
> I wish we had a Zen of Go and followed it.
>

You may be interested in this: https://go-proverbs.github.io/


>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em sáb, 29 de jun de 2019 às 20:18, Denis Cheremisov <
> denis.cheremi...@gmail.com> escreveu:
>
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2B%3DiygtUkrJLW1jP9f-Q-YtgkjJnSGVg6rJYW%3DD8jvrjYZwWZw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0wJYeCxhSTxKotOs3XnGLx5LAWPdEFr%2BR5m2C-wd9yjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Tyler Compton]

Sorry, forgot to CC on my last email. Here it is again:

And you must understand the specific: you are solving relatively hard
> problems developing language called Go with low mistake cost and we are
> solving simple problems with a DSL called Go but our mistake cost is much
> higher than yours.
>

Sorry, I'm not sure I understand. Who is the "you" and "we" in these
circumstances? I should be clear, I'm not a Go core team member and I had
nothing to do with the creation of the original "try" proposal. I've just
been involved in the proposal and anti-proposal discussion and noticed a
shift in tone.

I thought you are trying to be as practical as possible making a language
> with such a retarded yet somehow usable type system in XXI. But this recent
> proposal raises some suspicions...
>

What is XXI? Are you referring to Go's type system?

On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov <
denis.cheremi...@gmail.com> wrote:

> And prepare for wider audience in shitty “try” proposal after 1 July.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Tyler Compton]

If anyone hasn't seen it, an issue with the "proposal" tag was created
earlier on the Go issue tracker titled "Proposal: leave "if err != nil"
alone?" (here ). This issue seems to have
resonated with a lot of people, which may be an important data point when
considering the try proposal , but I was
surprised to see how poorly the discussion has gone. There are quite a few
"me too" comments, a few image-only posts, some less than stellar personal
conduct, and overall not a lot of nuanced discussion. I feel that perhaps
these kinds of anti-proposals should be discouraged because they're
inherently reactionary, which seems to get the discussion off on the wrong
foot.

That said, this anti-proposal attracted a whole new group of Go users that
I don't remember from the original try proposal discussion, which was
mostly dominated by ten or twenty participants. The discussion was better,
but the number of active users was much smaller. I wonder if there's a way
to better engage a larger portion of the Go user base while still
encouraging healthy, technical 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3iym9EM_SKtFvyHNgusVF2yL3p1O4dgCs7_VPUnRzGJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go GTK vs QT for Linux

[Tyler Compton]

Just noticed that I mentioned the wrong package. The runtime package for
GTK is libgtk-3-0.

On Mon, Jun 17, 2019 at 9:48 AM Tyler Compton  wrote:

> I haven't personally used this library, but I'd think you'd only
> need libgtk-3-dev and libappindicator3-dev at compile-time. You should be
> able to get away with the smaller runtime packages libgtk-3-dev
> and libappindicator3-1 once your application is built.
>
> On Mon, Jun 17, 2019 at 6:56 AM Subramanian Sridharan <
> clawsonfir...@gmail.com> wrote:
>
>> Hi guys
>>
>> I've been fiddling around this <https://github.com/getlantern/systray> 
>> package
>> which uses GTK bindings in Go to achieve systray functionality.
>> But it depends on *libgtk-3-dev *and* libappindicator3-dev *which amount
>> to around 300 MB.
>>
>> Have you guys come across any other package that implements GTK or QT
>> binding in Go?
>>
>> How do GTK and QT weight against each other with respect to Go?
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/c9d629e6-4e09-4c1a-ac69-906cd259f2af%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/c9d629e6-4e09-4c1a-ac69-906cd259f2af%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0__xK-J5ztz5GcLCq7sCtZAqf29mWtuzP38648RiC3iA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go GTK vs QT for Linux

[Tyler Compton]

I haven't personally used this library, but I'd think you'd only
need libgtk-3-dev and libappindicator3-dev at compile-time. You should be
able to get away with the smaller runtime packages libgtk-3-dev
and libappindicator3-1 once your application is built.

On Mon, Jun 17, 2019 at 6:56 AM Subramanian Sridharan <
clawsonfir...@gmail.com> wrote:

> Hi guys
>
> I've been fiddling around this  package
> which uses GTK bindings in Go to achieve systray functionality.
> But it depends on *libgtk-3-dev *and* libappindicator3-dev *which amount
> to around 300 MB.
>
> Have you guys come across any other package that implements GTK or QT
> binding in Go?
>
> How do GTK and QT weight against each other with respect to Go?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c9d629e6-4e09-4c1a-ac69-906cd259f2af%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0PAiuSnoWysjmmgBV5_P3PK2HS1XdKJaXDiA3ufhFTtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Bugs on switch

[Tyler Compton]

Andrew is right, but I'll also add that if you really do want fallthrough
semantics, you can use the "fallthrough" keyword:
https://play.golang.com/p/x2gBb905Hj0

Go opts to make the somewhat uncommon case of fallthrough explicit, and the
more common "break" case implicit. A bit surprising for new Go programmers
but it does allow for most switch statements to be quite a bit less verbose.

On Mon, Jun 17, 2019 at 7:35 AM Andrew Klager 
wrote:

> I'm going to guess, based on the "break" statement in the final case, that
> you expect each of the case statements without a break to fall through to
> the nest case. Go does not work like that. By default, each case, whether
> there's any action taken or not, breaks. Take a look at this to accomplish
> what you're probably looking for: https://play.golang.org/p/0aXXjoshOk9
>
> On Mon, Jun 17, 2019 at 9:26 AM  wrote:
>
>> i write example code standard switch statement
>> https://play.golang.org/p/kOplHDBk8Df
>>
>> program exited without print something.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/88c11740-e4a2-43af-8d4f-45c986cc55df%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CABn4WMUt%2BD30_OuKORFnMJL6okHYU5TVHKpX-rEqyyJ_Y15DKw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3sj63znKC8YSo6FTnj3-UJPRoOuGqxvGUemCLo4pNjVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] cgo libnice binding will stuck

[Tyler Compton]

Beyond just mailing list etiquette, you'll probably get better responses if
you provide your code in plain text. I think that some of the more
responsive people in golang-nuts use text-only email viewers, though that's
only a guess!

I took the liberty of transcribing this one, free of charge :)

func (a *Agent) GatherCandidates() error {
a.mtx.Lock()
defer a.mtx.Unlock()
fmt.Println("GatherCandidates1")
rv := int(C.nice_agent_gather_candidates(a.agent, C.guint(a.stream)))
if rv == 0 {
return errors.New("failed to gather candidates")
}
fmt.Println("GatherCandidates2")
return nil
}

On Wed, May 22, 2019 at 3:09 AM xiang liu  wrote:

> Sorry about this.
>
> 在 2019年5月22日星期三 UTC+8下午4:43:27，Jan Mercl写道：
>>
>> On Wed, May 22, 2019 at 10:05 AM xiang liu  wrote:
>>
>> Please use only plain text for source code in emails. Where available,
>> a link to play.golang.org is also good. Thanks.
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1379f6a2-e700-43ed-8cf6-c633ea567d1b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2_63yEwDu1-4aWi0WBUW82xL9JqMwf3726DGkwwHQH0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Http Handler to produce static content

[Tyler Compton]

> Sorry I don't quite understand -- my go application IS my webserver.
>

This is a topic that has confused me in the past. In the simple case where
you build a Go executable and get requests from it directly, your Go
application *is* your web server. However, it's common in industry to put a
system like nginx in front of your Go executable that takes care of serving
static content like images, JavaScript, CSS, and so on to the user without
consulting your Go application at all. Then, when this web server gets a
request on and endpoint that it doesn't know how to serve, like an API
call, it will forward that request to your Go application.

With a setup like this, you're able to concentrate on writing business
logic in Go and configure caching and static resource management elsewhere.
In these cases, the application in front of your Go application is the "web
server" because it is in charge of directly serving resources to the
client. Your Go application might be called the "web application" because
it is in charge of doing application-specific tasks. It isn't strictly
necessary to adopt this format just to cache static resources, but if your
needs become more complicated in the future it might be something worth
considering :)


> Are you saying Go net/http is not capable of doing what I'm asking?
>
> On Sun, May 19, 2019 at 9:59 AM satyendra singh
>  wrote:
> >
> > Hi Tong,
> > You can use a webserver between browser and your go application which
> will take care of header modification for browser caching.
> >
> > Thanks and regards,
> > Satyendra
> >
> > On Sun, 19 May, 2019, 7:26 PM Tong Sun,  wrote:
> >>
> >> Hi,
> >>
> >> How to have http.Handle / http.HandleFunc to produce static content
> that browser will use their caches without downloading every time?
> >>
> >> For a simplest http.HandleFunc, like the following,
> >>
> >> func sayHello(w http.ResponseWriter, r *http.Request) {
> >>message := "Hello "
> >>
> >>w.Write([]byte(message))
> >> }
> >>
> >>
> >>
> >> Thet HTTP Header it produce is:
> >>
> >> HTTP/1.1 200 OK
> >> Date: Sun, 19 May 2019 13:46:32 GMT
> >> Content-Length: 6
> >> Content-Type: text/plain; charset=utf-8
> >>
> >>
> >> I.e., the "Date:" part is changing all the time, even if I've added a
> "last-modified" Header field.
> >>
> >> What's the solution? Thx
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAMmz1OeBW5rp4RcfYtC%3Dk%3DpeX%3DdizF5G9Gv0Y1dgm5%2BG3%3DZBYA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2mC%2BvRQgWoMN-Sx-9AvrobDBobWug4etbQsk2rxC8MNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Random panic in production with Sprintf

[Tyler Compton]

I took a quick look and yes, it uses unsafe to convert between byte slices
and strings. I don't know enough to say that it's the problem but here's an
example:

https://github.com/valyala/fasthttp/blob/645361952477dfc16938fb2993065130ed7c02b9/bytesconv.go#L380

On Thu, May 2, 2019 at 5:16 PM Burak Serdar  wrote:

> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ  wrote:
> >
> > No use of C via CGO at all.
> >
> > Afaik, there isn't any unsafe use of the string, we are basically
> reading it from a get parameter (fasthttp server) on an http request and
> then adding it into this structure, most of the times is just a 5 char
> string. Out of several millions requests, this panic happens.
>
> Does this "fasthttp" have any unsafe pointers?
>
>
> >
> > I failed to find any kind of race using go race detector, I'm currently
> doing some more debugging, hopefuly I should have more info/tests soon.
> >
> > El jueves, 2 de mayo de 2019, 20:44:33 (UTC-3), Burak Serdar escribió:
> >>
> >> On Thu, May 2, 2019 at 3:56 PM Ian Lance Taylor 
> wrote:
> >> >
> >> > On Thu, May 2, 2019 at 2:50 PM Anthony Martin 
> wrote:
> >> > >
> >> > > What version of Go are you using?
> >> > >
> >> > > XXX ZZZ  once said:
> >> > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076)
> >> > > > /usr/local/go/src/fmt/print.go:448 +0x132
> >> > > > fmt.(*pp).printArg(0xc023c17740, 0x9978e0, 0xc016a68a30, 0x76)
> >> > > > /usr/local/go/src/fmt/print.go:684 +0x880
> >> > > > fmt.(*pp).doPrintf(0xc023c17740, 0xa6e22f, 0x5, 0xc048c27818,
> 0x1, 0x1)
> >> > > > /usr/local/go/src/fmt/print.go:1112 +0x3ff
> >> > > > fmt.Sprintf(0xa6e22f, 0x5, 0xc048c27818, 0x1, 0x1, 0x80, 0xa36200)
> >> > > > /usr/local/go/src/fmt/print.go:214 +0x66
> >> > >
> >> > > This shows signs of memory corruption. The last argument passed to
> >> > > fmtString (0xc00076) should be the same as the last argument
> >> > > passed to printArg (0x76 or 'v') but it has some high bits set.
> Also,
> >> > > the pointer to the format string data changes from 0xa6e22f (which
> is
> >> > > probably in the .rodata section of the binary) to 0x0.
> >> > >
> >> > > Something is amiss.
> >> >
> >> > The change from 0x76 to 0xc00076 does not necessarily indicate a
> >> > problem.  The stack backtrace does not know the types.  The value here
> >> > is a rune, which is 32 bits.  The compiler will only set the low order
> >> > 32 bits on the stack, leaving the high order 32 bits unset.  So the
> >> > 0xc0 could just be garbage left on the stack.
> >> >
> >> > I don't *think* the format string is changing.  I think the 0 is from
> >> > the string being printed, not the format string.  They both happen to
> >> > be length 5.
> >>
> >> There's something that doesn't make sense here. The 0 is from the
> >> string being printed, it is not the format string. But how can that
> >> be?
> >>
> >> Even if there is a race, the string cannot have a 0 for the slice, can
> >> it? So the other option is when Sprintf is called, the string being
> >> printed is already corrupt. Can there be an overflow somewhere that is
> >> somehow undetected? Any unsafe use in the program?
> >>
> >>
> >> >
> >> > Ian
> >> >
> >> > --
> >> > 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 golan...@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.
>

-- 
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: Is it possible to simplify this snippet?

[Tyler Compton]

On Wed, May 1, 2019 at 7:28 PM  wrote:

> if rl.IsKeyDown(rl.KeyA) { p.Rect.X-- }
> if rl.IsKeyDown(rl.KeyD) { p.Rect.X++ }
> if rl.IsKeyDown(rl.KeyW) { p.Rect.Y-- }
> if rl.IsKeyDown(rl.KeyS) { p.Rect.Y++ }
>

It's worth mentioning though that this will not survive a gofmt.

In general, I've found that Go does not provide a lot of options to shorten
code like this especially if you, like most people, use gofmt. There have
been times when this has frustrated me too, but I do think your original
code is the easiest solution to read.


> On Wednesday, May 1, 2019 at 8:38:10 PM UTC+8, гусь wrote:
>>
>> if rl.IsKeyDown(rl.KeyA) {
>> p.Rect.X -= 1
>> }
>> if rl.IsKeyDown(rl.KeyD) {
>> p.Rect.X += 1
>> }
>> if rl.IsKeyDown(rl.KeyW) {
>> p.Rect.Y -= 1
>> }
>> if rl.IsKeyDown(rl.KeyS) {
>> p.Rect.Y += 1
>> }
>>
> --
> 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] Go if else syntax .. suggested replacement

[Tyler Compton]

>
> There are many counter-examples. What is the likelihood that someone who
> is not familiar with the "?" operator will be familiar with the operators
> for getting (*) and dereferencing (&) a pointer. And what is "<-"?
> Certainly people not familiar with Go will initially be confused by
> operators related to channels.
>

>
If you allow people to use pointers, will they use pointers to pointers to
> pointers to pointers?
>

Sure, every language feature has a complexity cost and a chance for abuse.
However, the win for having pointers is, to me, a thousand times more
significant than that of the ternary operator, so it helps outweigh the
drawbacks that pointers introduce.


> On Thu, Apr 25, 2019 at 9:19 AM Sam Whited  wrote:
>
>> On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
>> > Are there really developers that find this unreadable?
>> >
>> > color := temperature > 80 ? “red” : “green”
>>
>> Yes.
>>
>> What is "?"? If I've never seen that before I have no easy way to search
>> for that, and a random symbol me nothing about what it does. Go
>> specifically tries to stick to keywords because even if you've never
>> seen them before it's generally easier to figure out what they do (or to
>> search for them if you're not sure).
>>
>> Not to mention that even if you do know what they do, that specific
>> statement isn't the problem. If you allow people to do that, they'll end
>> up trying to nest it 5 levels deep. Go tries not to give people the
>> tools to shoot themselves in the foot for some tiny perceived advantage.
>>
>> —Sam
>>
>> --
>> 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.
>>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> --
> 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] cracking the go language aplication

[Tyler Compton]

Could you provide some more details on what it is you want to do? Are you
looking to decompile a Go executable?

On Wed, Apr 17, 2019 at 12:23 PM smn shilla  wrote:

> Hi all
> Please anyone who know to crack the go application.exe please assist me
>
> --
> 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: Can't figure out modules when depending on multi module repo

[Tyler Compton]

Since this is a mailing list, editing the post wouldn't help you much
anyway. As soon as you make the original post it gets sent to everyone's
email as-is. Best just to do exactly what you did and follow up with more
info.

On Mon, Apr 8, 2019 at 7:29 AM Vladislav Mitov 
wrote:

> Since when I can't edit posts? Strange.
>
> The debug info was from before I pushed the first service to gitlab. Here
> is the correct one:
>
> WORK=/tmp/go-build828045533
>> Fetching
>> https://gitlab.company.com/vladislav.mitov/service/pkg/client?go-get=1
>> Parsing meta tags from
>> https://gitlab.company.com/vladislav.mitov/service/pkg/client?go-get=1
>> (status code 200)
>> get "gitlab.company.com/vladislav.mitov/service/pkg/client": found meta
>> tag get.metaImport{Prefix:"
>> gitlab.company.com/vladislav.mitov/service/pkg/client", VCS:"git",
>> RepoRoot:"https://gitlab.company.com/vladislav.mitov/service/pkg/client"}
>> at https://gitlab.company.com/vladislav.mitov/service/pkg/client?go-get=1
>> mkdir -p /home/master/Workspace/go/pkg/mod/cache/vcs # git2
>> https://gitlab.company.com/vladislav.mitov/service/pkg/client
>> # lock
>> /home/master/Workspace/go/pkg/mod/cache/vcs/ff338c7e0e1ae4b0396cc581329d58d26a1e39c55116c29c97948a4a64c797a9.lock#
>> /home/master/Workspace/go/pkg/mod/cache/vcs/ff338c7e0e1ae4b0396cc581329d58d26a1e39c55116c29c97948a4a64c797a9
>> for git2 https://gitlab.company.com/vladislav.mitov/service/pkg/client
>> cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/ff338c7e0e1ae4b0396cc581329d58d26a1e39c55116c29c97948a4a64c797a9;
>> git ls-remote -q
>> https://gitlab.company.com/vladislav.mitov/service/pkg/client
>> 0.599s # cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/ff338c7e0e1ae4b0396cc581329d58d26a1e39c55116c29c97948a4a64c797a9;
>> git ls-remote -q
>> https://gitlab.company.com/vladislav.mitov/service/pkg/client
>> Fetching https://gitlab.company.com/vladislav.mitov/service/pkg?go-get=1
>> Parsing meta tags from
>> https://gitlab.company.com/vladislav.mitov/service/pkg?go-get=1 (status
>> code 200)
>> get "gitlab.company.com/vladislav.mitov/service/pkg": found meta tag
>> get.metaImport{Prefix:"gitlab.company.com/vladislav.mitov/service/pkg",
>> VCS:"git", RepoRoot:"
>> https://gitlab.company.com/vladislav.mitov/service/pkg"} at
>> https://gitlab.company.com/vladislav.mitov/service/pkg?go-get=1
>> mkdir -p /home/master/Workspace/go/pkg/mod/cache/vcs # git2
>> https://gitlab.company.com/vladislav.mitov/service/pkg
>> # lock
>> /home/master/Workspace/go/pkg/mod/cache/vcs/09f143e37d8fc82802c4ce59d3fec02d19347221fe46af231bfa83e1bacd4f7a.lock#
>> /home/master/Workspace/go/pkg/mod/cache/vcs/09f143e37d8fc82802c4ce59d3fec02d19347221fe46af231bfa83e1bacd4f7a
>> for git2 https://gitlab.company.com/vladislav.mitov/service/pkg
>> cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/09f143e37d8fc82802c4ce59d3fec02d19347221fe46af231bfa83e1bacd4f7a;
>> git ls-remote -q https://gitlab.company.com/vladislav.mitov/service/pkg
>> 0.643s # cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/09f143e37d8fc82802c4ce59d3fec02d19347221fe46af231bfa83e1bacd4f7a;
>> git ls-remote -q https://gitlab.company.com/vladislav.mitov/service/pkg
>> Fetching https://gitlab.company.com/vladislav.mitov/service?go-get=1
>> Parsing meta tags from
>> https://gitlab.company.com/vladislav.mitov/service?go-get=1 (status code
>> 200)
>> get "gitlab.company.com/vladislav.mitov/service": found meta tag
>> get.metaImport{Prefix:"gitlab.company.com/vladislav.mitov/service",
>> VCS:"git", RepoRoot:"https://gitlab.company.com/vladislav.mitov/service"}
>> at https://gitlab.company.com/vladislav.mitov/service?go-get=1
>> mkdir -p /home/master/Workspace/go/pkg/mod/cache/vcs # git2
>> https://gitlab.company.com/vladislav.mitov/service
>> # lock
>> /home/master/Workspace/go/pkg/mod/cache/vcs/d80081ef39cfc1cf3eab3e5e235a832587b977ece2e7753ea963c6c7a32a5cf4.lock#
>> /home/master/Workspace/go/pkg/mod/cache/vcs/d80081ef39cfc1cf3eab3e5e235a832587b977ece2e7753ea963c6c7a32a5cf4
>> for git2 https://gitlab.company.com/vladislav.mitov/service
>> cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/d80081ef39cfc1cf3eab3e5e235a832587b977ece2e7753ea963c6c7a32a5cf4;
>> git ls-remote -q https://gitlab.company.com/vladislav.mitov/service
>> 0.707s # cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/d80081ef39cfc1cf3eab3e5e235a832587b977ece2e7753ea963c6c7a32a5cf4;
>> git ls-remote -q https://gitlab.company.com/vladislav.mitov/service
>> go: finding gitlab.company.com/vladislav.mitov/service latest
>> cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/d80081ef39cfc1cf3eab3e5e235a832587b977ece2e7753ea963c6c7a32a5cf4;
>> git -c log.showsignature=false log -n1 '--format=format:%H %ct %D'
>> 378a88163ba50ea08f9ce738c442403ed4826a0e
>> 0.007s # cd
>> /home/master/Workspace/go/pkg/mod/cache/vcs/d80081ef39cfc1cf3eab3e5e235a832587b977ece2e7753ea963c6c7a32a5cf4;
>> git -c log.showsignature=false log -n1 '--format=format:%H %ct %D'
>> 378a88163ba50ea08f9ce738c442403ed4826a0e
>> cd
>> /home/mast

Re: [go-nuts] Question regarding gob

[Tyler Compton]

When we think of pointers as what they literally are, an address to a space
in memory, it sounds reasonable for Gob to not support them. Things get
more unclear when we consider that, in practice, Go programmers often use
pointers as a replacement for option types. Without pointers, I don't know
how an optional value could be transported using Gob, unless you're willing
to add an additional flag to your data structure to indicate if some data
is considered present.

On Tue, Mar 26, 2019 at 9:48 AM Michael Jones 
wrote:

> To be clear here as educators, it is important to point out that exporting
> / persisting / sending a pointer is an awkward concept.
>
> The normal meanings of sending data beyond an executing program have no
> direct use for the pointer’s literal value; “the thing at location 12345 in
> the memory of a program that ran last year” is not much help.
>
> On the other hand, one might imagine pointers being like file names and
> then recreate both content and references during reading. The export format
> could persist all the typed, pointed to values in tables, and then for each
> pointer variable exported send instead advice like “put the address of the
> 456th element of the table for type C things in this pointer slot.”
>
> A persistent format supporting this way of recreating the semantics of
> pointers is very much like an archive format (Zip) with support for
> symbolic links. It is not particularly hard to implement, but it is a
> “heavyweight” approach. My sense is that the common desire in export tools
> is high speed and byte efficiency so it is natural that Gob and other
> mechanisms adopt the “pointers don’t make sense for export” argument.
>
> Michael
>
> On Tue, Mar 26, 2019 at 6:01 AM roger peppe  wrote:
>
>>
>>
>> On Mon, 25 Mar 2019 at 14:45, Glen Huang  wrote:
>>
>>> Thanks for the reply, Sameer.
>>>
>>> Being able to directly send go types is a really big plus for me, I
>>> wonder if I really want to use gob, are there any recommended rpc choices?
>>>
>>
>> Note that gob has at least one significant limitation when encoding Go
>> types - it doesn't know about pointers - in general it encodes a pointer by
>> omitting a field. So if you want to send a slice of a pointer type where
>> some elements can be nil, you're out of luck:
>> https://play.golang.org/p/ThVUT_M0hjR
>>
>> --
>> 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.
>

-- 
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: WebAssembly: Auto-generating Go bindings for javascript/DOM from the Web Standards.

[Tyler Compton]

Hi Martin,

This is really exciting work! I would definitely recommend posting this as
an announcement in its own thread, I'm sure a lot of people are looking for
something like this. Thanks for taking the initiative!

On Sun, Feb 24, 2019 at 6:17 AM Martin Juhlin 
wrote:

> Hi,
>
> I have started to work on DOM binding based on WebIDL and a binding
> generator. I don't have full WebIDL support yet, but it does process idl
> from about 80 specifications. See https://gowebapi.github.io for more
> details.
>
>Martin
>
> Den fredag 28 december 2018 kl. 13:16:22 UTC+1 skrev Chris FractalBach:
>>
>> This is in the context of compiling Go to webassembly that will be used
>> with javascript.
>>
>>
>> *Currently:*
>>
>> We have`syscall/js` which has stuff like this:
>> ```go
>> js.Global().Get("document").Call("createElement", "div")
>> ```
>>
>> What it could be:
>> ```go
>> js.document.createElement("div")
>> ```
>>
>>
>>
>> *Why?*
>>
>> This would make writing stuff for webassembly WAY easier.
>> Auto-generating it would allow it to update definitions whenever the
>> standards
>> are updated.  Which would make it easier to maintain.
>>
>> Also, if there's going to be significant usage of
>> Go -> webassembly -> web browser and javascript
>> then having all the types and definitions auto-generated would save on
>> tons
>> of boilerplate abstractions that people will inevitably create for their
>> own sanity.
>>
>> Advantages:
>> - more natural to use
>> - more readable
>> - type safe
>>
>> Disadvantages:
>> - less flexible
>> - when the APIs are updated, it might result in loss of
>> backwards-compatibility
>>
>>
>>
>>
>> *How?*
>>
>> WebIDL --> Go source code
>>
>> - https://www.w3.org/TR/WebIDL/
>> - https://heycam.github.io/webidl/
>> - https://www.w3.org/TR/DOM-Level-3-Core/idl-definitions.html
>>
>>
>>
>>
>> Technical reports published by the W3C that include programming language
>>> interfaces have typically been described using the Object Management
>>> Group’s Interface Definition Language (IDL) [OMGIDL]. The IDL provides a
>>> means to describe these interfaces in a language independent manner.
>>> Usually, additional language binding appendices are included in such
>>> documents which detail how the interfaces described with the IDL correspond
>>> to constructs in the given language.
>>
>> https://www.w3.org/TR/WebIDL/#introduction
>>
>>
>>
>>
>>
>> *A Possible Conversion:*
>>
>> *From WebIDL:*
>> ```
>> [Exposed=Window]
>> interface Paint { };
>>
>>
>> [Exposed=Window]
>> interface SolidColor : Paint {
>>   attribute double red;
>>   attribute double green;
>>   attribute double blue;
>> };
>>
>>
>> [Exposed=Window]
>> interface Pattern : Paint {
>>   attribute DOMString imageURL;
>> };
>>
>>
>> [Exposed=Window, Constructor]
>> interface GraphicalWindow {
>>   readonly attribute unsigned long width;
>>   readonly attribute unsigned long height;
>>
>>
>>   attribute Paint currentPaint;
>>
>>
>>   void drawRectangle(double x, double y, double width, double height);
>>
>>
>>   void drawText(double x, double y, DOMString text);
>> };
>>
>> ```
>> Example From: https://heycam.github.io/webidl/
>>
>>
>>
>> *To Go:*
>>
>> This is probably not the best way to do it, but is an example of how it
>> might look.
>>
>> type Paint struct {}
>>
>>
>> type SolidColor struct {
>>  Red   float64
>>  Green float64
>>  Blue  float64
>> }
>>
>>
>> type GraphicalWindow struct {
>>  widthuint32
>>  height   uint32
>>  CurrentPaint Paint
>> }
>>
>>
>> func (gw *GraphicalWindow) drawRectangle(x, y, width, height float64) {
>> // syscall
>> }
>>
>>
>> func (gw *GraphicalWindow) drawText(x, y float64, text string) {
>> // syscall
>> }
>>
>>
>>
>>
>>
>>
>> I know there are some existing examples of Go bindings for DOM,
>> but I don't think they are auto-generated from WebIDL,
>> Which I imagine would be easier to maintain in the long-run.
>>
>>
>>
>>
>> Anybody have thoughts on this?
>>
>>
>>
>>
>> --
> 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] why go get does not work outside a module?

[Tyler Compton]

It sounds to me like you would want to set GO111MODULE to "auto". My
understanding is that then "go get" will behave like it used to when run
inside of the GOPATH or in a directory tree without a go.mod file.

Here's a bit of information about it on the wiki:
https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior


On Fri, Feb 15, 2019 at 6:23 AM Manlio Perillo 
wrote:

> I have started to use go modules recently, and I have set GO111MODULE=on.
>
> It was unexpected to found that go get does not work outside a module.
> As an example:
> $ go get github.com/davecheney/godoc2md
> go: cannot determine module path for source directory /home/manlio
> (outside GOPATH, no import comments)
>
> When I used go get inside a module I found that:
>
> 1. It saves the downloaded packages in the go mod cache
> 2. It Installs the command in GOBIN
>
> These two points can be also done outside a module.
>
> 3. Add an (indirect) entry in the require section in the go.mod file
>
> The new entry will, however, be removed by go mod tidy.
>
> Is it really necessary that go get must only work inside a module?
>
>
> Thanks
> Manlio Perillo
>
> --
> 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] Golang closures, counter-intuitive behaviour

[Tyler Compton]

For what it's worth, there is a popular proposal up that suggests changing
for range loops to redefine their variables for every iteration:
https://golang.org/issues/20733

On Mon, Feb 11, 2019 at 4:58 PM Burak Serdar  wrote:

> On Mon, Feb 11, 2019 at 5:48 PM Slawomir Pryczek 
> wrote:
> >
> > Hi Guys,
> >
> > When looking at this code below, you can see that the function will get
> LAST value of i which is incremented inside the loop, but t is somehow
> copied and taken inside a function so closure is created and it is bound to
> current value of t, so we'll have its current value in function. This is
> strange as t and i is defined on the same code block level (t will be
> discarded at the same time as i, after the loop).
> >
> > I always thought that t would need to be passed explicitly to goroutine
> to retain current value (which i did). But why assigning value in a loop is
> treated differently in this regard than a straight assignment? Any URL
> where such "special cases" are documented? Isn't it kind of design flaw,
> because this seem very confusing that loop is creating single value and
> simple assignment is creating multiple copies? Maybe you consider changing
> this in go2?
>
>
> This is well-documented behavior. The first link I can find is:
> https://github.com/golang/go/wiki/CommonMistakes
>
> The common mistake is to think that the for-loop variable is captured
> as value in the closure. It is not, it is a reference, and the
> go-routine sees the value of the variable when it runs, not when it is
> created.
>
> >
> > https://play.golang.org/p/6vx_qDOk51g
> >
> > 10 1
> > 10 0
> > 10 9
> > 10 8
> > 10 7
> > 10 6
> > 10 5
> > 10 4
> > 10 3
> > 10 2
> >
> >
> > Thanks,
> > Slawomir.
> >
> >
> > -
> > package main
> > import (
> > "fmt"
> > "time"
> > )
> >
> > func main() {
> > for i := 0; i < 10; i++ {
> > t := i
> > go func() {
> > time.Sleep(time.Millisecond * 100)
> > fmt.Println(i, t)
> > }()
> > }
> > time.Sleep(time.Millisecond * 1000)
> > }
> >
> >
> >
> > --
> > 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] Mismatched types work sometimes?

[Tyler Compton]

Constant expressions like 'A' or 3 or named constants like "const x = 7"
are what Go calls "untyped constants". The type of these constants are
determined by the context in which they're used. For example:

const myConst = 3
myFloat := 2.5
fmt.Println(myFloat + myConst)
fmt.Println(myFloat + 3)

Both of the above cases work because myConst and the literal 3 are untyped
constants that take on the type float64 automatically.

You can also declare typed constants, which no longer have these type
inference properties.

const myConst int = 3
myFloat := 2.5
fmt.Println(myFloat + myConst)  // No longer works

If you're curious about the details, I would check out the section of the
language spec on this: https://golang.org/ref/spec#Constants

On Mon, Feb 11, 2019 at 9:37 AM Jamie Caldwell 
wrote:

> Hello,
>
> Can you help?
>
> https://play.golang.org/p/XfJZ3h06p60
>
> Why does 'A' work, when first assigning it to a variable doesn't?
>
> Thank you,
> Jamie.
>
> --
> 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: Providing more detail after a nil pointer dereference

[Tyler Compton]

Oh, and I just realized I linked completely the wrong issue. Here is a good
link: https://golang.org/issues/30116


On Sat, Feb 9, 2019 at 10:31 AM Tyler Compton  wrote:

> > A possibly better idea would be to report the line and column number.
> That should uniquely identify which code caused the problem, both for nil
> pointer and indexing. The question is how much additional space it would
> take to encode column numbers.
>
> I like this idea a lot though I admit that it probably wouldn't be worth a
> significant increase in binary size. Would doing this mean holding two
> integers (line, column) in the binary for every dereference? I could
> definitely see that getting expensive.
>
> > You can almost always disambiguate the problem dereference with some
> judicious uses of \n, if the problem is reproducible.
>
> This is the solution I've come up with too :) It usually is good enough,
> just not for those rare but nasty situations where a panic only happens
> occasionally and in production.
>
> Thanks for the insight!
>
> On Fri, Feb 8, 2019 at 8:10 PM 'Keith Randall' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> 27605 is more about providing the values that caused the panic, not the
>> source location. It is still the case that even with 27605 multiple
>> indexing operations on the same line are not distinguished (unless
>> knowledge of the application lets you disambiguate using the values).
>> For nil pointer dereferences, there's no value to report. Or, there's
>> exactly one value to report, which isn't helpful.
>>
>> Mentioning the variable is problematic for the reason you mentioned.
>>
>> A possibly better idea would be to report the line and column number.
>> That should uniquely identify which code caused the problem, both for nil
>> pointer and indexing. The question is how much additional space it would
>> take to encode column numbers.
>> You can almost always disambiguate the problem dereference with some
>> judicious uses of \n, if the problem is reproducible.
>>
>> On Thursday, February 7, 2019 at 4:36:01 PM UTC-8, Tyler Compton wrote:
>>>
>>> After reading https://golang.org/issues/27605 (proposal: report indexes
>>> for bounds failure), I started to wonder why we don't do something similar
>>> with nil pointer dereferences.
>>>
>>> I've more than once found myself in a situation where I'm inspecting a
>>> nil pointer dereference panic and it ends up on a line where any number of
>>> variables could have been the nil pointer in question. It would be helpful
>>> in these circumstances to get a message like "attempt to dereference
>>> variable 'myvar', which is a nil pointer" or something along those lines.
>>> Here is a toy example that causes a panic on a line where there are many
>>> variables that could have been the problematic nil pointer.
>>> https://play.golang.com/p/mmkOOU3M3lU
>>>
>>> My guess as to why I've never seen this in a language before is because
>>> dereferencing doesn't always happen on a named variable. For example,
>>> `getSomePointer().field` could result in a nil pointer dereference, but
>>> there's no variable name to put in the panic. Maybe then the panic message
>>> would be "attempt to dereference anonymous variable, which is a nil
>>> pointer", which is still slightly less ambiguous than the current panic
>>> message. Do you think a feature like this could be useful, even with its
>>> inherent limitations?
>>>
>> --
>> 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: Providing more detail after a nil pointer dereference

[Tyler Compton]

> A possibly better idea would be to report the line and column number.
That should uniquely identify which code caused the problem, both for nil
pointer and indexing. The question is how much additional space it would
take to encode column numbers.

I like this idea a lot though I admit that it probably wouldn't be worth a
significant increase in binary size. Would doing this mean holding two
integers (line, column) in the binary for every dereference? I could
definitely see that getting expensive.

> You can almost always disambiguate the problem dereference with some
judicious uses of \n, if the problem is reproducible.

This is the solution I've come up with too :) It usually is good enough,
just not for those rare but nasty situations where a panic only happens
occasionally and in production.

Thanks for the insight!

On Fri, Feb 8, 2019 at 8:10 PM 'Keith Randall' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> 27605 is more about providing the values that caused the panic, not the
> source location. It is still the case that even with 27605 multiple
> indexing operations on the same line are not distinguished (unless
> knowledge of the application lets you disambiguate using the values).
> For nil pointer dereferences, there's no value to report. Or, there's
> exactly one value to report, which isn't helpful.
>
> Mentioning the variable is problematic for the reason you mentioned.
>
> A possibly better idea would be to report the line and column number. That
> should uniquely identify which code caused the problem, both for nil
> pointer and indexing. The question is how much additional space it would
> take to encode column numbers.
> You can almost always disambiguate the problem dereference with some
> judicious uses of \n, if the problem is reproducible.
>
> On Thursday, February 7, 2019 at 4:36:01 PM UTC-8, Tyler Compton wrote:
>>
>> After reading https://golang.org/issues/27605 (proposal: report indexes
>> for bounds failure), I started to wonder why we don't do something similar
>> with nil pointer dereferences.
>>
>> I've more than once found myself in a situation where I'm inspecting a
>> nil pointer dereference panic and it ends up on a line where any number of
>> variables could have been the nil pointer in question. It would be helpful
>> in these circumstances to get a message like "attempt to dereference
>> variable 'myvar', which is a nil pointer" or something along those lines.
>> Here is a toy example that causes a panic on a line where there are many
>> variables that could have been the problematic nil pointer.
>> https://play.golang.com/p/mmkOOU3M3lU
>>
>> My guess as to why I've never seen this in a language before is because
>> dereferencing doesn't always happen on a named variable. For example,
>> `getSomePointer().field` could result in a nil pointer dereference, but
>> there's no variable name to put in the panic. Maybe then the panic message
>> would be "attempt to dereference anonymous variable, which is a nil
>> pointer", which is still slightly less ambiguous than the current panic
>> message. Do you think a feature like this could be useful, even with its
>> inherent limitations?
>>
> --
> 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] Providing more detail after a nil pointer dereference

[Tyler Compton]

After reading https://golang.org/issues/27605 (proposal: report indexes for
bounds failure), I started to wonder why we don't do something similar with
nil pointer dereferences.

I've more than once found myself in a situation where I'm inspecting a nil
pointer dereference panic and it ends up on a line where any number of
variables could have been the nil pointer in question. It would be helpful
in these circumstances to get a message like "attempt to dereference
variable 'myvar', which is a nil pointer" or something along those lines.
Here is a toy example that causes a panic on a line where there are many
variables that could have been the problematic nil pointer.
https://play.golang.com/p/mmkOOU3M3lU

My guess as to why I've never seen this in a language before is because
dereferencing doesn't always happen on a named variable. For example,
`getSomePointer().field` could result in a nil pointer dereference, but
there's no variable name to put in the panic. Maybe then the panic message
would be "attempt to dereference anonymous variable, which is a nil
pointer", which is still slightly less ambiguous than the current panic
message. Do you think a feature like this could be useful, even with its
inherent limitations?

-- 
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: multiple binaries from a single directory with go modules?

[Tyler Compton]

What alternative do you recommend?

On Fri, Jan 18, 2019 at 4:53 PM Space A.  wrote:

> Yes/ Don't use make and makefiles.
>
>
>
>> Is there some clever way of structuring a project like this with go
>> modules that I haven't figured out yet?
>>
>> Thanks,
>>
>> Tycho
>>
> --
> 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] golang for coding interviews

[Tyler Compton]

Hi Naveen,

Others may disagree but my take is that Go is not a great coding interview
language. The lack of many built-in data structures is a big one, but those
closing curly braces and other syntax can be a big pain when writing on a
whiteboard. In cases where only general programming knowledge is being
tested for, I would pick Python so long as you're comfortable in the
language. It has more data structures available and is simply easier to
write on a whiteboard. Other conveniences like all, any, and list
comprehensions also come in handy when time to write code and available
space for code is at a premium.

Of course, traits that make a language better for interviews don't always
make the language better for production use. Go is still my go-to language
for many other things :)

On Thu, Jan 10, 2019 at 4:56 PM Naveen Neelakanta <
naveen.b.neelaka...@gmail.com> wrote:

> Hi All,
>
> I wanted to use Golang for coding interviews, however, I can't import
> basic data structures like stack, heap, the queue on to IDEs. Is there a
> way to achieve this.
>
> Thanks,
> Naveen
>
> --
> 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] if/switch statements as expressions

[Tyler Compton]

There is some precedent. Python has an if expression of sorts that is
distinct from its if statements:

print(value1 if condition else value2)

And in all Lisp dialects I'm familiar with, if is an expression:

(print (if condition value1 value2))

Not to say that this means Go should support it necessarily.

On Wed, Dec 19, 2018 at 12:16 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Dec 19, 2018 at 9:09 PM Viktor Kojouharov 
> wrote:
>
>
> > I'm interested to know whether it was considered (I can't imagine that
> it wasn't) for if and switch statements to be expressions instead
>
> I can't imagine it was considered. Is there a precedence in other
> language? Not even C supports that.
>
>
> --
>
> -j
>
> --
> 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: pass interface

[Tyler Compton]

If my interpretation of the question is correct, I think it boils down to
whether or not it's possible to get the reflect.Type of a type in order to
pass it to a function without first creating an instance of that type. I
don't think it's possible but I would be interested to hear from someone
who knows more.

On Mon, Dec 10, 2018 at 1:28 PM Dan Kortschak  wrote:

> No, it is possible, but you need to pass the pointer to the interface.
> You can then use reflect to interrogate the interface value.
>
> The bigger question, and one that would help here would be what is it
> that you are actually trying to achieve.
>
> On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > Yes, this is what I'm trying to do!
> > Perhaps this is not possible.
> >
> > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels 
> > wrote:
> >
> > >
> > > I think what the OP wants is:
> > >
> > > type A interface{}
> > > type B interface{}
> > >
> > > ...
> > > PrintInterface(A)
> > >
> > > Meaning they want to pass the interface definition to some method.
> > >
> > > At least that’s what I am guessing.
> > >
> > > On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
> > >
> > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > >
> > > package main
> > >
> > > import (
> > > "fmt"
> > > "reflect"
> > > )
> > >
> > > func main() {
> > > test := interface{}("test")
> > > printInterfaceValue(test)
> > > }
> > >
> > > func printInterfaceValue(i interface{}) {
> > > switch testing := i.(type) {
> > > case interface{}:
> > > fmt.Println("is interface, with value:", testing)
> > > case string:
> > > fmt.Println("is not interface")
> > > }
> > >
> > > fmt.Println("reflect.Type is", reflect.TypeOf(&i).Elem())
> > > }
> > >
> > > Output:
> > >
> > > is interface, with value: test
> > > reflect.Type is interface {}
> > >
> > >
> > >
> > >
> > >
> > >
> > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert
> > > Engels
> > > написал:
> > > >
> > > >
> > > > I mean reflect.Type not a type that is an interface.
> > > >
> > > > On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
> > > >
> > > > Of course. When you "pass a value whose type implements the
> > > > interface" as
> > > > an interface argument to a function, you in fact pass an
> > > > *interface*.
> > > >
> > > >
> > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark
> > > > Volkmann
> > > > написал:
> > > > >
> > > > >
> > > > > Is it possible to pass an interface to a function in Go? I
> > > > > don’t want to
> > > > > pass a value whose type implements the interface, I want to
> > > > > pass the
> > > > > interface.
> > > > >
> > > > > --
> > > > > R. Mark Volkmann
> > > > > Object Computing, Inc.
> > > > >
> > > > --
> > > > 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.
> > >
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
>
> --
> 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.
>


-- 
Tyler Compton
Student of Software Engineering
Arizona State University

-- 
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: different behaviour in return: error is shadowed during return

[Tyler Compton]

As you are seeing, Go does not allow you to do a naked return when one of
the named return values is being shadowed by another variable. If you take
a look at the "Return statements" section in the Go Language Specification
[1], it mentions this restriction:

> Implementation restriction: A compiler may disallow an empty expression
list in a "return" statement if a different entity (constant, type, or
variable) with the same name as a result parameter is in scope at the place
of the return.

On line 203, it may look like err is being shadowed here, but it's not. The
:= operator will only define a new variable if a variable with that same
name hasn't already been defined in the same stack frame. On line 200,
m3u8List is being defined, but err is simply being assigned a new value.
This is because err is already defined in this stack frame in the form of a
named return variable.

On line 210, we're now in a new stack frame. Because of that, it is now
possible to redefine the err variable by shadowing the one defined as a
named return in the previous stack frame. Now that a named return variable
is being shadowed, naked returns will no longer compile. It's the rules :)

On line 216, we're no longer using a naked return, so the rule about
shadowing no longer applies.

As for why this restriction is in place, I'm not sure. I would be
interested to hear an explanation. However, I would assume it's to reduce
confusion. Naked returns can already be confusing, and adding shadowing
into the mix could make it very difficult to figure out what values are
actually being returned.

1. https://golang.org/ref/spec#Return_statements

On Tue, Nov 27, 2018 at 7:03 PM hui zhang  wrote:

> happen in  go 1.10.2   1.11.2
>
> 在 2018年11月28日星期三 UTC+8上午11:02:47，hui zhang写道：
>>
>> ./main.go:212:4: err is shadowed during return
>>
>> check code above only line 212 report err
>> however line 203 and 212 are almost the same case. but did not report err.
>>
> --
> 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.
>


-- 
Tyler Compton
Student of Software Engineering
Arizona State University

-- 
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 modules and vendor: redundant features?

[Tyler Compton]

> People keep adding stuffs into Go and later find themselves unable to
remove existing features due to the backward compatibility promise. Go 1.11
is a different beast than Go 1.0, and is significantly more complex.

For what it's worth, I don't believe that tooling is covered under
the backward compatibility promise, so it is possible to remove things
without a new major version bump. Of course, this would have to be done
with care, but it's not out of the question. I know that this is a bit of
an aside but it's worth keeping in mind.

On Mon, Nov 19, 2018 at 4:40 PM  wrote:

>
> I recall reading from Russ Cox that vendoring will be removed in the
> future and be replaced by explicit caching with modules.
>
> --
> 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.
>


-- 
Tyler Compton
Student of Software Engineering
Arizona State University

-- 
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] go modules and gocode

[Tyler Compton]

My understanding is the mdempsky branch is not expected to work with Go
modules. This fork apparently will: https://github.com/stamblerre/gocode

That said, I haven't personally had any luck with that fork either. I would
love to hear from someone who's had success with gocode/vim-go/modules.

On Fri, Nov 9, 2018 at 1:03 PM Keith Brown  wrote:

> Using vim-go
>
> Has anyone gotten gocode (https://github.com/mdempsky/gocode) to work
> with golang modules?
>
> In my GOPATH directory, i see
>
> gopath
>   pkg
> mod
>  cache
>download
>  github.com
>
> But for whatever reason, its not autocompletting the modules.
>
> Is there anything else I should be doing? In addion, is there a better
> solution for vim users?
>
>
> --
> 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] Why fmt.Print() debug statements aren't showing up in dev_appserver.py logs?

[Tyler Compton]

App Engine's logging library requires a context object as its first
argument, so I'm not sure which log package you're using right now. The
correct way to use the App Engine logging library is to create a context
somewhere early on in the request's life-cycle and use it as the first
argument to the log functions.

ctx := appengine.NewContext(r)  // Where r is your *http.Request object
log.Infof(ctx, " handleMain() called")

Let me know what behavior you see doing this.

On Fri, Nov 9, 2018 at 1:15 PM Bryan  wrote:

> I replaced the fmt.Print statement  with:
>
> log.Infof(" handleMain() called")
>
> The local server still serves the page correctly but the log Info is not
> showing up in the dev_appserver.py logs in Terminal.
>
> On Thursday, November 8, 2018 at 5:57:06 PM UTC-5, Tyler Compton wrote:
>
>> I believe that the most correct way to do logging with App Engine is to
>> use the log package (https://godoc.org/google.golang.org/appengine/log).
>> This, to my understanding, allows App Engine to categorize logs based on
>> which request they are from alongside some other metadata. Do you see
>> printouts using this package?
>>
>> On Thu, Nov 8, 2018 at 1:02 PM Bryan  wrote:
>>
> The local webserver renders the page correctly at http://localhost:8080/
>>>
>>> I"m using the code from
>>> https://github.com/GoogleCloudPlatform/golang-samples/tree/master/appengine/helloworld
>>>
>>> I put a print statement at line 20 of hello.go :
>>>
>>> fmt.Print(" hello.handle() called")
>>>
>>> I'm starting the local server with:
>>>
>>> $ dev_appserver.py app.yaml
>>>
>>> Shouldn't the print statement be showing up in the osX Terminal window
>>> server logs?
>>>
>>> I could have sworn I was not having this issue a few weeks ago. How do I
>>> check that the wrapper is capable of processing STDOUT?
>>>
>>> How do I fix 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...@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] Why fmt.Print() debug statements aren't showing up in dev_appserver.py logs?

[Tyler Compton]

I believe that the most correct way to do logging with App Engine is to use
the log package (https://godoc.org/google.golang.org/appengine/log). This,
to my understanding, allows App Engine to categorize logs based on which
request they are from alongside some other metadata. Do you see printouts
using this package?

On Thu, Nov 8, 2018 at 1:02 PM Bryan  wrote:

> The local webserver renders the page correctly at http://localhost:8080/
>
> I"m using the code from
> https://github.com/GoogleCloudPlatform/golang-samples/tree/master/appengine/helloworld
>
> I put a print statement at line 20 of hello.go :
>
> fmt.Print(" hello.handle() called")
>
> I'm starting the local server with:
>
> $ dev_appserver.py app.yaml
>
> Shouldn't the print statement be showing up in the osX Terminal window
> server logs?
>
> I could have sworn I was not having this issue a few weeks ago. How do I
> check that the wrapper is capable of processing STDOUT?
>
> How do I fix 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.
>

-- 
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] go:nosplit

[Tyler Compton]

I'm also surprised to hear that go:nosplit can be used in arbitrary
packages. I would be curious to know if these directives are covered under
the compatibility promise within the limited guarantees they provide.

On Fri, Oct 5, 2018 at 2:47 PM Scott Cotton  wrote:

> Thanks much for the info.
>
> Do you have any more pointers about how one may assess whether or ensure
> that a stack overflow check
> is not necessary in order to safely use this directive?
>
> Scott
>
>
> On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor  wrote:
>
>> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton  wrote:
>> >
>> > I have for the longest time thought of "go:nosplit" as a
>> runtime-specific
>> > thing which wasn't available to arbitrary package authors.
>> >
>> > Then, I found this from "go doc compile"
>> >
>> > ```
>> > //go:nosplit
>> >
>> > The //go:nosplit directive specifies that the next function declared in
>> the
>> > file must not include a stack overflow check. This is most commonly
>> used by
>> > low-level runtime sources invoked at times when it is unsafe for the
>> calling
>> > goroutine to be preempted.
>> > ```
>> >
>> > I am interested in knowing
>> > 1. Can it indeed be used in arbitrary packages?
>>
>> Yes.
>>
>> > 2. Does it indeed prevent the emission/addition of pre-emption
>> instructions
>> > in the function it annotates?
>>
>> Well, yes and no.  What it does is disable the stack overflow check at
>> function entry.  At present the stack overflow check is also used  as
>> a goroutine-preemption check.  So disabling the stack overflow check
>> disables the goroutine-preemption check at function entry.  And in Go
>> 1.11 that is the only preemption check, so in Go 1.11 go:nosplit does
>> indeed disable preemption for a function.  But there are no promises
>> that there will never be any other sort of preemption check.  In fact
>> we definitely do want to add other preemption checks that occur at
>> points other than function entry (issues #10958, #24543).  And if
>> there is another preemption check, there are no promises that
>> go:nosplit will disable that check.
>>
>> > 3. Can it be used with gccgo?
>>
>> Yes.
>>
>> Ian
>>
>
>
> --
> Scott Cotton
> http://www.iri-labs.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.
>

-- 
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] Proposal: Implicit Method Signatures

[Tyler Compton]

When I do want to define my own custom getter, how might I tell the
language that my new method is a custom getter and not just a method with
no arguments and one return value? I think if Go were to have properties,
they would have to be explicitly marked as a property in some way to avoid
this.

For what it's worth, I'm personally mixed on properties. They do provide a
nice syntax for accessing information from an object but they can sometimes
make it harder to see what's going on in a program. When I read code in
languages with properties, it can be hard for me to know which expressions
result in some external code being run and which ones don't.

On Fri, Sep 28, 2018 at 3:45 PM 'Peter Müller' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> The other day I had an interesting idea: What if all exported fields have
> an implicit getter. Like e.g.
>
> type Human struct {
> Age  uint
> Name string
> }
>
> would implicitly get the methods:
>
> func (h Human) Name() string {
> return h.Name
> }
> func (h Human) Age() uint {
> return h.Age
> }
>
>
> *When defining an interface*
>
> type Being interface {
> Age()  uint
> Name() string
> }
>
> getters would not have to be defined if they simply return a property.
> This would remove boilerplate code. But if a modification or calculation is
> needed you would just make a private property and define a custom getter.
>
>
> *Backwards compatibility*
>
> Explicitly defined getters would be overriding the implicit ones and
> therefore not change behaviour of existing programs.
>
>
>
> This is only an idea. I post this to know if either this is a valid idea
> worth considering putting into go or if there is just something wrong with
> my style of coding and using interfaces.
>
> --
> 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] Operator Overloading Implies Generics?

[Tyler Compton]

I believe what you're discussing in this case is function or method
overloading. Operator overloading refers to the ability to specify custom
behavior for operators like +, -, etc.

On Sat, Sep 8, 2018 at 6:58 PM Rick 
wrote:

> With recent discussion concerning the possible introduction of generics in
> Go 2, it occurs to me to ask about support for operator overloading in Go
> 2. By this I mean support for functions having the same name but different
> signature:
>
> func foo(x int) int ...
>
> func foo(x string) bool ...
>
> func foo(x int, y string) ...
>
> etc.
>
> Is support for operator overloading implied by support for generics? Is it
> possible to have one with the other? To be honest, I've been more bothered
> by the lack of operator overloading than by the absence of generics. And (I
> assume) no new syntax would be required to support overloading. Or would
> there?
>
>
> --
> 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] Why can't we use < > for the Go generic parameters ?

[Tyler Compton]

I agree with Alan and I actually think the parentheses-based syntax is
fine. In Go as it is now, there is no case where using brackets on a
variable results in a call to code somewhere else in the project. It's
always some kind of indexing operation. Parenthesis have a history of doing
this with function calls. If we adopt the bracket syntax for generics, it
may become a bit harder when reading code to see which lines call out to
another part of the project and which lines don't. This is often a problem
with languages that support properties and operator overloading. I
appreciate Go's clarity in this matter and I think the bracket syntax might
undermine it a bit.

On Fri, Sep 7, 2018 at 6:31 AM  wrote:

> Whilst I could live with square brackets, I prefer round brackets too and
> still would do even if angle brackets were available.
>
> This is because when I see different types of brackets following an
> identifier, I (and probably many others) tend to associate them as follows:
>
> 1. square brackets  ->  arrays/slices/maps
>
> 2. curly brackets ->  function bodies, struct/interface declarations
>
> 3. angle brackets->  ordering operators
>
> 4. round brackets->  function declarations, function invocations, type
> conversions, grouping stuff together
>
> So I agree with rog that #4 best fits the existing Go ethos.
>
>
> On Friday, September 7, 2018 at 12:47:59 PM UTC+1, rog wrote:
>
>> Personally, I'm happy with the choice to use round brackets.
>>
>> Go started down this road a long time ago, in my view, by making type
>> conversions look like function calls.
>>
>> When `typename(x)` is qualitatively different from `value(x)`, I think
>> it's quite reasonable that `x(typename)` is qualitatively different
>> from `x(value)` too.
>>
>> In other words, I think it's nicely regular and fits Go's aesthetic well.
>>
>>
>> On 7 September 2018 at 09:05, Sebastien Binet  wrote:
>> > Bikesheding mode on...
>> >
>> > On Fri, Sep 7, 2018, 00:06 jimmy frasche  wrote:
>> >>
>> >> I'd quite prefer [] over (). It would make F[t](v) distinct from
>> >> F(x)(y) even if it's not distinct from m[x](y).
>> >
>> >
>> > One could add a dot, like for type checking:
>> > F.[T](y)
>> >
>> > Yet another rule to learn... :)
>> >
>> > -s
>> >
>> >
>>
> >> On Thu, Sep 6, 2018 at 3:02 PM Ian Lance Taylor 
>> wrote:
>> >> >
>> >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche 
>>
> >> > wrote:
>> >> > >
>> >> > > Wouldn't there be an issue with fp := AFunc[int] ?
>> >> >
>> >> > I don't think so.  AFunc[int] would be parsed as an index operation,
>> >> > and after name lookup it would resolve into either an array lookup
>> or
>> >> > a function instantiation, depending on the meaning of `int` in the
>> >> > current scope.  This is not very different from the way that t(v)
>> >> > resolves to either a function call or a type conversion after name
>> >> > lookup.  It's quite different from using <>, which has to be parsed
>> >> > quite differently depending on whether it is an instantiation or a
>> >> > comparison.
>> >> >
>> >> >
>> >> > > Though for that matter I wouldn't mind if the type part were
>> repeated
>> >> > > for instantiations like AFunc[type int] or even AFunc(type int)
>> >> >
>> >> > That would be possible but seems unnecessary.  I personally would
>> >> > prefer to avoid it.
>> >> >
>> >> >
>> >> > > For that matter, always writing type would let you use < > since
>> the
>> >> > > parser could plausibly enter a separate mode when it hit the <
>> token
>> >> > > followed by type.
>> >> > >
>> >> > > Noisy but obvious at a glance what's happening.
>> >> >
>> >> > Yes, that is true except for the >> issue.
>> >> >
>> >> > Ian
>> >>
>> >> --
>> >> 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: Os/Exec problematic quotation marks

[Tyler Compton]

Oh, you beat me to it :) Good luck on your project!

On Wed, Sep 5, 2018 at 9:35 AM Tyler Compton  wrote:

> I believe what Volker is suggesting is to create your command in this way:
>
> cmnd := exec.Command("C:/Program Files/internet explorer/iexplore.exe",
> "--nogui", "--start", "AGT_BANCL_CobrosManuales")
>
> Have you given this a shot? The exec.Command function expects each
> space-separated argument of the command to be a separate argument. I
> suspect that exec.Command is seeing spaces in the one argument you're
> giving it and assuming it needs quotes.
>
> On Wed, Sep 5, 2018 at 9:17 AM Daniel Estiven Rico Posada <
> danielrico.pos...@gmail.com> wrote:
>
>> Yeah, but i want that when i execute an application from Go exec, be the
>> same that if i executed from cmd directly. But actually, the execution from
>> go exec have quotation marks in the args.  is there something possibility?
>>
>>
>>
>> El miércoles, 5 de septiembre de 2018, 3:32:44 (UTC-5), Daniel Estiven
>> Rico Posada escribió:
>>>
>>> Hello,
>>>
>>> Actually i'm working in a go application that receive a http request and
>>> start some windows assistants. (RPA's)
>>>
>>> The assistants are executed from windows cmd:
>>> > "C:/path/file.exe" --args
>>>
>>> When i start the assistant from cmd manually, in the task Manager i see
>>> the arguments without quotation marks. But if i open the assistant from go
>>> application the arguments are left with quotation marks.
>>>
>>>
>>>
>>> In golang i'm using the lib *"os/exec":*
>>>
>>> Internet explorer is only an example.
>>>
>>> *Do you know what's the reason?*
>>>
>>> Thanks.
>>>
>>>
>>> --
>> 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: Os/Exec problematic quotation marks

[Tyler Compton]

I believe what Volker is suggesting is to create your command in this way:

cmnd := exec.Command("C:/Program Files/internet explorer/iexplore.exe",
"--nogui", "--start", "AGT_BANCL_CobrosManuales")

Have you given this a shot? The exec.Command function expects each
space-separated argument of the command to be a separate argument. I
suspect that exec.Command is seeing spaces in the one argument you're
giving it and assuming it needs quotes.

On Wed, Sep 5, 2018 at 9:17 AM Daniel Estiven Rico Posada <
danielrico.pos...@gmail.com> wrote:

> Yeah, but i want that when i execute an application from Go exec, be the
> same that if i executed from cmd directly. But actually, the execution from
> go exec have quotation marks in the args.  is there something possibility?
>
>
>
> El miércoles, 5 de septiembre de 2018, 3:32:44 (UTC-5), Daniel Estiven
> Rico Posada escribió:
>>
>> Hello,
>>
>> Actually i'm working in a go application that receive a http request and
>> start some windows assistants. (RPA's)
>>
>> The assistants are executed from windows cmd:
>> > "C:/path/file.exe" --args
>>
>> When i start the assistant from cmd manually, in the task Manager i see
>> the arguments without quotation marks. But if i open the assistant from go
>> application the arguments are left with quotation marks.
>>
>>
>>
>> In golang i'm using the lib *"os/exec":*
>>
>> Internet explorer is only an example.
>>
>> *Do you know what's the reason?*
>>
>> Thanks.
>>
>>
>> --
> 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] Cross platform native(no dependencies) GUI options.

[Tyler Compton]

I did a bit more research and found https://github.com/BurntSushi/xgb which
interacts with X directly without the need for C bindings, so it is
possible to at least open a window without any cgo. However, I don't know
of a way that you can have cross-platform accelerated graphics without
using OpenGL, which will require cgo. Unfortunately, I'm not sure if what
you want is really feasible, and if it is you may not be very happy with
the results.

There are GUI libraries out there for Go that require cgo but support all
major platforms. What is it about cgo that you're hoping to avoid?

On Sun, May 27, 2018 at 2:57 PM  wrote:

> I just do not want it to have cgo and it should be perfect.
>
>
> On Sunday, May 27, 2018 at 2:55:06 PM UTC-7, Tyler Compton wrote:
>
>> I'm not sure if it's actually feasible to write a GUI library without
>> external libraries. A GUI that runs Linux will need to interact with an X
>> server or a Wayland compositer, and the library will have to interact with
>> their APIs somehow.
>>
>> On Sun, May 27, 2018, 14:19  wrote:
>>
>>> Yeah, the ones suggested all use cgo though.
>>>
>>>
>>> On Sunday, May 27, 2018 at 2:08:17 PM UTC-7, Sebastien Binet wrote:
>>>
>>>> There was very recently a thread about this on Reddit:
>>>>
>>>>
>>>> https://www.reddit.com/r/golang/comments/8m5icy/cross_platform_native_gui_library/
>>>>
>>>> sent from my droid
>>>>
>>>> On Sun, May 27, 2018, 22:51  wrote:
>>>>
>>> Hello,
>>>>>
>>>>> I would like you guys to suggest some GUI libraries that do not have
>>>>> any HTML/CSS or C bindings, are cross platform and require no 
>>>>> dependencies.
>>>>>
>>>>> When I say native, I mean no dependencies. I do not mean native to the
>>>>> OS. This would be great but I don't see any available that have no C
>>>>> bindings. I understand that to create a native to the OS experience there
>>>>> must be calls to the OS API which in most cases use the C language.
>>>>>
>>>>> Before anyone asks why I do not want C bindings, it is because they do
>>>>> not have good cross compilation support or good compile speeds.
>>>>>
>>>>> Suggestions appreciated, Thanks so much!
>>>>>
>>>>> --
>>>>> 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] Cross platform native(no dependencies) GUI options.

[Tyler Compton]

I'm not sure if it's actually feasible to write a GUI library without
external libraries. A GUI that runs Linux will need to interact with an X
server or a Wayland compositer, and the library will have to interact with
their APIs somehow.

On Sun, May 27, 2018, 14:19  wrote:

> Yeah, the ones suggested all use cgo though.
>
>
> On Sunday, May 27, 2018 at 2:08:17 PM UTC-7, Sebastien Binet wrote:
>
>> There was very recently a thread about this on Reddit:
>>
>>
>> https://www.reddit.com/r/golang/comments/8m5icy/cross_platform_native_gui_library/
>>
>> sent from my droid
>>
>> On Sun, May 27, 2018, 22:51  wrote:
>>
> Hello,
>>>
>>> I would like you guys to suggest some GUI libraries that do not have any
>>> HTML/CSS or C bindings, are cross platform and require no dependencies.
>>>
>>> When I say native, I mean no dependencies. I do not mean native to the
>>> OS. This would be great but I don't see any available that have no C
>>> bindings. I understand that to create a native to the OS experience there
>>> must be calls to the OS API which in most cases use the C language.
>>>
>>> Before anyone asks why I do not want C bindings, it is because they do
>>> not have good cross compilation support or good compile speeds.
>>>
>>> Suggestions appreciated, Thanks so much!
>>>
>>> --
>>> 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] Global variable not used, but it works fine

[Tyler Compton]

Go does not flag unused global variables, it is intended functionality.
I've personally found that unused global variables have a higher chance at
being benign than local variables, but there's probably an argument to be
made for flagging globals, too.

On Sat, Apr 21, 2018, 06:30  wrote:

>  What did you do?
> https://play.golang.org/p/aryK9Btv5kH
>
>  What did you expect to see?
> There should be a error "declared and not used"
>
>  What did you see instead?
> It seems work fine.
>
>  System details
>
> ```
> go version go1.10.1 windows/amd64
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="C:\Users\zps\AppData\Local\go-build"
> GOEXE=".exe"
> GOHOSTARCH="amd64"
> GOHOSTOS="windows"
> GOOS="windows"
> GOPATH="C:\Users\zps\go"
> GORACE=""
> GOROOT="C:\Go"
> GOTMPDIR=""
> GOTOOLDIR="C:\Go\pkg\tool\windows_amd64"
> GCCGO="gccgo"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments
> -fmessage-length=0
> -fdebug-prefix-map=C:\Users\zps\AppData\Local\Temp\go-build846935694=/tmp/go-build
> -gno-record-gcc-switches"
> GOROOT/bin/go version: go version go1.10.1 windows/amd64
> GOROOT/bin/go tool compile -V: compile version go1.10.1
> ```
>
> --
> 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] formatting question/issue

[Tyler Compton]

My understanding is that this is a consequence of the semicolon insertion
rules Go uses. The Go parser actually uses semicolons internally, but they
are inserted before parsing so that the programmer doesn't have to.

Semicolons are added to the end of a line if the line ends with:
 - an identifier
 - an integer, floating-point, imaginary, rune, or string literal
 - one of the keywords break, continue, fallthrough, or return
 - one of the operators and delimiters ++, --, ), ], or }
(Taken from this article:
https://medium.com/golangspec/automatic-semicolon-insertion-in-go-1990338f2649
)

In your second example on line 18, "true" is an identifier so a semicolon
would be inserted there. Obviously this would make for invalid code,
because that place is not the end of an expression. Adding a comma lets the
semicolon inserter know that there is more to this expression so it doesn't
add a semicolon.

It's an interesting suggestion to make the comma obligatory. My first
impression is that it would lead to even more surprises to programmers from
other languages.

On Mon, Apr 9, 2018 at 4:32 PM Alex Dvoretskiy 
wrote:

> Hello Golangnuts,
>
> Why there is no difference if the last comma exists?
>
> {'A', 'B', 'C', 'E'}
> or
> {'A', 'B', 'C', 'E',}
>
> both are valid.
>
>
> Sometimes it causes little troubles. For example, the second snippet
> wouldn't compile, because of different formatting. But these two snippets
> are identical technically. So, you have to add this last comma to keep the
> formatting you want. Which can be annoying.
>
> https://play.golang.org/p/4Vav9n2_NIc
>
> https://play.golang.org/p/pr2h6_FBxFn
>
>
> I think it's very good idea to make the last comma obligatory.
>
> --
> 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.