[go-nuts] How do you use traceback ?

[wilk]

There is a proposal to add a trace only opt-in at error level.
Only on this error I like to know the method and line.

*Apart* to know if it's something useful to add in the standard lib or
not (to don't pollute the github issue), how do you use the traceback in
errors ?

Do you add a full traceback like with pkg/errors ?
No traceback, decorate the error is enough ?
A mix like the proposal ?
Depends of the project ?

For me it depends of the project but after using pkg/errors a lot I
tried no traceback at all, it was working and it force me to think two
time how I decorate each error, that's eventually more accurate than a
traceback. And now in few places I see that my decorate looks like a
small traceback "I'm in method X and I call Y: %v"

Thought ?

-- 
wilk

-- 
You received this message because you are subscribed 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/u715e0%24130j%241%40ciao.gmane.io.

[go-nuts] Re: HTTP Proxy in Go

[wilk]

On 22-04-2021, Van Fury wrote:
> --=_Part_322_998422299.1619075183467
> Content-Type: multipart/alternative; 
>   boundary="=_Part_323_2099960923.1619075183467"
>
> --=_Part_323_2099960923.1619075183467
> Content-Type: text/plain; charset="UTF-8"
>
>
> Hi,
>
> I have to implement an HTTP forwarding proxy in Go which can be used in 
> production and need advice from Go experts. 
> Any advice like which Go library is best to use and other things to take 
> not of when implementing it.

I'm not an expert but I use the proxy of httputil without any issue. I'm
using forwarding to legacy app with Go new app in front.

-- 
wilk

-- 
You received this message because you are subscribed 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/s5rv6u%24gir%241%40ciao.gmane.io.

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

[wilk]

On 18-03-2021, Tyler Compton wrote:

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

+1 

-- 
wilk

-- 
You received this message because you are subscribed 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/s30g04%24ie7%241%40ciao.gmane.io.

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

[wilk]

On 17-03-2021, Ian Lance Taylor wrote:
> On Wed, Mar 17, 2021 at 4:28 AM Space A.  wrote:
>>
>> Can you provide any proof that there was an open public discussion?
>
> What kind of proof would you find to be acceptable?  Can you give an
> example of something that I could say that you would consider to be a
> good answer to that question?  Thanks.

It is still possible to write a formal proposal "canceling generics" if
someone find now a good reason, right ? (at the time of modules i
believe it was).

Thanks for your patience

>
> Ian
>
>
>
>> ср, 17 мар. 2021 г. в 02:12, Ian Lance Taylor :
>>>
>>> On Tue, Mar 16, 2021 at 6:51 AM Space A.  wrote:
>>> >
>>> > > (To be clear, your original claim was that there *was* no discussion - 
>>> > > which is at least easy to address, because it's clearly not true. There 
>>> > > was over three years of active discussion on this)
>>> >
>>> > No, and I can repeat, there was no (public) discussion on whether the 
>>> > idea of generics in Go should be completely dropped. It *was* always a 
>>> > "discussion" of how to improve and implement generics in a Go way, but 
>>> > not of generics themselves as something to be avoided by all means.
>>>
>>> I'm sorry, but that simply isn't the case.  Many different people at
>>> many different times suggested that the idea of adding generics should
>>> be dropped.  Those ideas were discussed, supported, opposed, and so
>>> forth.  It's been a long discussion over many years.
>>>
>>> Ian
>


-- 
wilk

-- 
You received this message because you are subscribed 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/s2vc5m%24sgd%241%40ciao.gmane.io.

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

[wilk]

On 16-03-2021, Space A. wrote:

>> This seems very dismissive of the many members of the community which
> *did* invest the time and energy to discuss the design for the past years.
> When the contracts design was announced in 2018
><https://blog.golang.org/go2draft>, the process was explained. Including
> the fact that it is a draft, which will see several revisions, that this
> process will likely take a couple of years and how we can participate in
> it. Many of us have seen that announcement and understood it for what it
> was and thus - even if (like me) they were opposed to the idea of generics
> in Go - decided to participate in it to do their best to ensure the outcome
> was a good design or a rejection.
>
> That's absolutely up to you, but some of us (including myself) can't invest
> so much time because we have to earn money for living.

Every body need to earn money for living. Generics will maybe help for
that. It's why we was a lot (in the community) to invest time discussing
this since years. I thanks Alex and others who have contributed a lot
more time than me. We should respect all this work.

-- 
wilk

-- 
You received this message because you are subscribed 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/s2qag8%24i2a%241%40ciao.gmane.io.

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

[wilk]

On 15-03-2021, Ian Lance Taylor wrote:
> On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com 
>  wrote:
>>
>> I am in favor of the proposal but I think that accounting for popularity 
>> votes is not a good measure of things.
>> A lot of people are at various stages of their technical journey in computer 
>> science and engineering and there has to be a weight given to the more 
>> technical opinions that is not reflected in the github upvote/downvote 
>> system.
>> At one point, everyone would have upvoted that the earth was flat.
>>
>> Just a note in passing :)
>
> Yes. 

Please don't fall into the trap !

You're truly impressive how you have been so attentive to all the
critics. Keep it !

I believe we've all learned a lot since one decade of discussion about
this.

Thanks

> I am not saying that the proposal was adopted because it had
> good support.  I am arguing against the suggestion that the proposal
> should not have been adopted because it had a lot of critics.
>
> Ian

-- 
wilk

-- 
You received this message because you are subscribed 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/s2q0ga%24m47%242%40ciao.gmane.io.

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

[wilk]

On 16-03-2021, Robert Engels wrote:

> Very well said.=20

+1

-- 
wilk

-- 
You received this message because you are subscribed 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/s2q03v%24m47%241%40ciao.gmane.io.

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

[wilk]

On 01-01-2021, Ian Lance Taylor wrote:
> On Fri, Jan 1, 2021 at 12:40 PM robert engels  wrote:
>>
>> I was thinking more of an internal api - maybe stdlib authors only - writing 
>> code similar to map.go to create an alternate map type, and allow selecting 
>> of that map type in the make() call. It would be more difficult to write the 
>> collections implementation, and the methods available are fixed to the 
>> current Go map syntax - but I think it would address a large segment of the 
>> need for generics without adding generics. I think many of the other use 
>> cases can be dealt with using interfaces - maybe having many of them 
>> predeclared in the stdlib for consistency.
>>
>> So then the issue becomes a purely technical one - how to write these 
>> implementations and have them integrated into the build.

+1

>
> Fair enough.

It could be a first step (genrics only in the stdlib) before opening
generics to everybody.

-- 
wilk

-- 
You received this message because you are subscribed 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/rsp6dk%243be%241%40ciao.gmane.io.

[go-nuts] Re: Signature Switch - third path to Go generics

[wilk]

On 31-12-2020, Ian Lance Taylor wrote:
> On Thu, Dec 31, 2020 at 10:37 AM Wojciech S. Czarnecki  
> wrote:
>>
>> I regard current Team's proposal a way better than the first iteration. But -
>> while I see a need for generic way to write common code, I also share
>> concerns about readability and future abuse of the materialized Go generics
>> being similar to "the other languages". I consciously did not patricipate in 
>> the
>> [Generics, please go 
>> away!](https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo)
>> bikeshed, but I would like to share an idea that may possibly reconcile both 
>> camps.
>>
>>"Signature switch" - readable generic code preserving the Go way.
>>
>> Generic function declaration is 
>> https://golang.org/ref/spec#Function_declarations
>> with at least one type in the Signature given as the ascii character "+" 
>> followed
>> by single capital ascii letter, further reffered to as "TypeLetter"; and 
>> with a single,
>> non empty, signature switch present in the function body:
>>
>> func f (x +T) (r +R) {  // generic function
>> switch func.(type) {  // Signature Switch here. Resolves at 
>> COMPILE TIME.
>> case func(x int) (r int): // call-site signature to match
>> r = x/2 // instantiated code, T and R are 
>> now ints
>> }
>> return r
>> }
>>
>> More to read at: https://play.golang.org/p/Q1ry4KPoOOJ
>>
>> Hope this helps,
>
> Thanks, it's an interesting idea.
>
> That said, one of the minimal requirements that I think applies to any
> generics proposal is the ability to write a compile-time-type-safe
> container, such as a concurrent hash map.  

I understand in his description that it's type safe at compile time.

>> switch func.(type) {  // Signature Switch here. Resolves at 
>> COMPILE TIME.
   
^

I like it this way, it's look like closure and immediatly understandable
for go users (maybe func f( x[T]) (r [R]) ?)

-- 
wilk

-- 
You received this message because you are subscribed 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/rsn1av%248fa%241%40ciao.gmane.io.

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

[wilk]

On 31-12-2020, Alex Besogonov wrote:

> I had a couple of reflective helpers that did this work through reflection, 
> but it was not clean and had broken more than once during refactorings. I 
> actually gave up on Go for this project and rewrote it in Python, resulting 
> in 10x (ten times) less lines of code.

The question is not how many lines of code to start but how to maintain
this code.
I found myself playing a lot with the magical possibilities of Python to
have very concise code but after years they become completely impossible
Maintain!

That said, i don't say that for your example, i can see where generics
will help to have maintainable code... Two sides...

I believe we have to choose where to put the cursor between the minimum
of generics possibilities for the maximum maintainability...

-- 
wilk

-- 
You received this message because you are subscribed 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/rsmsr2%24hk6%241%40ciao.gmane.io.

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

[wilk]

On 30-12-2020, robert engels wrote:
>
> --Apple-Mail=_053BD88E-EE7F-423A-AE3D-712B500390F8
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; charset="UTF-8"
>
> Agreed.
>
> I had proposed a different approach, where the built-in map and slice could=
>  have alternative implementations chosen during make(). 95% of generics usa=
> ge is collections. I think this would have retained the simplicity of Go a =
> bit better than generics - but at the end of day - generics are not =E2=80=
>=9Cdifficult". Bad programmers write bad code without generics.

If 95% of generics are collections the current draft is overkill.
What about a simplified version with only one generic type (like we do
with interface{}), without constraint as long as it can compile ?

func add(x, y GenericType) GenericType {
  return x + y
}

add(1,2) // add can compile : func add(x, y int) is generated
add("abc", "def") // can compile : func add(x, y string) is generated

add(1, "abc") // two differents type : error

GenericType will be like interface{} but instead of casting it'll
generate on the fly, at compile time the function with the type of each
functions call.
I believe it's too easy and i miss something already discussed...

-- 
wilk

-- 
You received this message because you are subscribed 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/rsk0bb%24tg6%241%40ciao.gmane.io.

[go-nuts] Re: Generics, please go away!

[wilk]

On 26-12-2020, Christian Staffa wrote:
> I would rather have a survey with generics specific question that would she=
> d a better light to this topic. at least now, after following this discussi=
> on. i also think that it could be good to add it but is it worth when it al=
> so adds complexity? then i would say no thank you. go is powerful and simpl=
> e but after that it would be powerful and complex. i think it would be bett=
> er for go to solve the error handling. this would also make the go code bet=
> ter readable which would help the language more than adding generics if it =
> is a good solution, i think =F0=9F=92=AD=20

Maybe adding generics will help handling error ?

-- 
wilk

-- 
You received this message because you are subscribed 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/rs73mc%24m03%241%40ciao.gmane.io.

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

[wilk]

On 24-12-2020, Sebastien Binet wrote:
> This is a multi-part message in MIME format.
>
> --b1_GrUsz2qka8Vf9CMQa2ukahUpPKrwyxBqPmoLYzM
> Content-Type: text/plain; charset="UTF-8"
>
> Like every other feature from Go.
> Think channels and goroutines.
> Or the reflect package. Or the unsafe one.
> Or big large fat interfaces.
> Or the empty interface.

Yes. If generics will be used like that i believe it will not break the
simplicity and community of Go.

-- 
wilk

-- 
You received this message because you are subscribed 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/rs20cn%24u25%241%40ciao.gmane.io.

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

[wilk]

On 24-12-2020, Marcin Romaszewicz wrote:

> Generics would allow for writing less code, and re-using it more. As long
> as it doesn't complicate the base language, why not? You don't have to use
> them :)

The only problem with Generics is when it will be abused. Maybe never,
how to know ?

The current draft has double sides. On one side it's really simple in the
way of Go, which is amazing for generic ! But on the other side,
because it'll be easy to use it can be abused.

-- 
wilk

-- 
You received this message because you are subscribed 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/rs1rb2%246mc%241%40ciao.gmane.io.

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

[wilk]

On 24-12-2020, Igor Cananea wrote:
> --9cfe9505b7311862
> Content-Type: text/plain; charset="UTF-8"
>
> While the example of ReverseSlice doesn't appear in my work experience, the
> concept of writing functions for slices independent of type is pretty
> common for me.

I like a lot how sort.Slice allow this. I did the same for all the need
of generics that I had.

-- 
wilk

-- 
You received this message because you are subscribed 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/rs1me3%24t74%241%40ciao.gmane.io.

[go-nuts] Re: Generics, please go away!

[wilk]

I think theres an opportunity to =
> have empathy with people who *are* in favor of generics. Because just like =
> you are frustrated that generics are just nice to have (i.e. you perceive t=
> heir actual benefit as insignificant), people on the other side of the aisl=
> e might be *just as* frustrated by you, because generics are just slightly =
> more complex (i.e. they perceive their actual costs as insignificant). Your=
>  frustration is valid, but so is theirs. ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
>  rgb(204,204,204);padding-left:1ex"> As I have said many times now, adding =
> stuff to Go comes with
> a heavy price, it opens the door for all the people who have been whining r>
> and complaining about Go for the past ten+ years to add further stuff that<=
> br>
> is nice to have, or change things they keep complaining about, =
> like how
> Go handles errors and what not.
>
> After generics gets added, its going to be something else next time, a=
> nd
> again and again. The list goes on and on about changes people want to
> make to Go. Not real life problems, just so-called nice to have=
> .
>
> No, the added and increased complexity I have witness in other
> programming languages over the past 3-4 decades, because of exactly
> things like this, is absolutely mind blowing. This must not happen to Go! r>
>
> -- 
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts group.
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.c=
> om/d/msgid/golang-nuts/17246551608725779%40iva4-6593cae50902.qloud-c.yandex=
> .net" rel=3D"noreferrer nofollow" target=3D"_blank" data-saferedirecturl=3D=
> "https://www.google.com/url?hl=3Denq=3Dhttps://groups.google.com/d/msg=
> id/golang-nuts/17246551608725779%2540iva4-6593cae50902.qloud-c.yandex.net=
> mp;source=3Dgmailust=3D1608839208893000usg=3DAFQjCNEEejduiYzwLc2i=
> N-77_DjGoQGuDQ">https://groups.google.com/d/msgid/golang-nuts/1724655160872=
> 5779%40iva4-6593cae50902.qloud-c.yandex.net.
>
>
> -- 
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts group.
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to golang-nuts...@googlegroups.com.<=
> /blockquote> tr">
> To view this discussion on the web visit https://groups.google.c=
> om/d/msgid/golang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%=
> 40mail.gmail.com?utm_medium=3Demailutm_source=3Dfooter" rel=3D"nofollo=
> w" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
>=3Denq=3Dhttps://groups.google.com/d/msgid/golang-nuts/CAEkBMfFVeWZcnM=
> tWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%2540mail.gmail.com?utm_medium%3Demail%=
> 26utm_source%3Dfootersource=3Dgmailust=3D1608839208893000usg=
>=3DAFQjCNEHWrFyipsGjUtPIeUdMXuDk__IQg">https://groups.google.com/d/msgid/go=
> lang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%40mail.gmail.=
> com.
>
>
> -- 
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts group.
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to golang-nuts...@googlegro=
> ups.com. k-word;line-break:after-white-space">
> To view this discussion on the web visit https://groups.google.c=
> om/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7bc2d9d3896cn%40googlegroups=
> .com?utm_medium=3Demailutm_source=3Dfooter" target=3D"_blank" rel=3D"n=
> ofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Denq=
>=3Dhttps://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7b=
> c2d9d3896cn%2540googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter=
> mp;source=3Dgmailust=3D1608839208893000usg=3DAFQjCNEpd4w7Yc9wxOLA=
> xjTiEBCA5YveGg">https://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f=
> -4920-a11c-7bc2d9d3896cn%40googlegroups.com.
>
>
>
>
> -- 
> You received this message because you are subscribed to the Google Groups &=
> quot;golang-nuts group.
> To unsubscribe from this group and stop receiving emails from it, send an e=
> mail to mailto:golang-nuts+unsubscr...@googlegroups.com;>golang-=
> nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.c=
> om/d/msgid/golang-nuts/5c3114cd-fcf4-4c17-aa92-026a8bb092b8n%40googlegroups=
> .com?utm_medium=3Demail_source=3Dfooter">https://groups.google.com/d/ms=
> gid/golang-nuts/5c3114cd-fcf4-4c17-aa92-026a8bb092b8n%40googlegroups.com>.
>
> --=_Part_8329_1642814539.1608758069173--
>
> --=_Part_8328_927921797.1608758069173--
>


-- 
wilk

-- 
You received this message because you are subscribed 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/rs1gpv%24144l%241%40ciao.gmane.io.

[go-nuts] Re: [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

[wilk]

On 23-12-2020, Ian Lance Taylor wrote:
> On Wed, Dec 23, 2020 at 9:54 AM wilk  wrote:
>>
>> https://go2goplay.golang.org/p/fTW3hJYNgfU
>>
>> type Stringer interface {
>>String() string
>> }
>>
>> Print[T Stringer](s []T)
>>
>> Print(s []Stringer)
>>
>> Both forms works.
>> How to prevent double way to do the same things that can be confusing ?
>
> Both forms work but they mean two different things.
>
> Print(s []Stringer) takes a slice of the type Stringer.
>
> Print[T Stringer](s []T) takes a slice of some type T, where T
> implements Stringer.
>
> For example, if MyInt implements Stringer, and I have a []MyInt, then
> I can call Print[T Stringer](s []T) but I can't call Print(s
> []Stringer), because a []Stringer is not a []MyInt.

I understand the differences. But i'm affraid someone who never used
Go before will use type parameters instead of interface which is more
idiomatic i think.
I mean it will be difficult to say, you could use type parameters but
you should use interface, or something like that...
I'm speaking about ease of learn Go2.

-- 
wilk

-- 
You received this message because you are subscribed 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/rs08pp%24p8m%241%40ciao.gmane.io.

[go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

[wilk]

Hi,

https://go2goplay.golang.org/p/fTW3hJYNgfU

type Stringer interface {
   String() string
}

Print[T Stringer](s []T) 

Print(s []Stringer)

Both forms works.
How to prevent double way to do the same things that can be confusing ?

-- 
wilk

-- 
You received this message because you are subscribed 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/rs0077%24vd9%241%40ciao.gmane.io.

[go-nuts] Re: Generics, please go away!

[wilk]

On 22-12-2020, Ian Lance Taylor wrote:
> On Tue, Dec 22, 2020 at 2:09 PM Martin Hanson
> wrote:
>>
>> @Ian, if you're succumbing to outside pressure, please don't.
>>
>> If you on the other hand is pro-generics to Go, then of course that is
>> your right.
>>
>> I for one doesn't hope that the future of Go is going to continue down
>> this road, with new proposals for change popping up on GitHub every
>> other day and surveys and possible outside pressure determining the
>> future of Go. I would very much like to know if this is going to be the
>> way it is.
>
> I am in favor of adding generics to Go if it can be done while
> preserving the clarity and simplicity of the language.  See
> https://blog.golang.org/why-generics (which I wrote).

Do you believe the last draft respect all the conditions you wrote or
does it still need improvements ?

It's difficult to measure "simplicity" when adding anything new...

-- 
wilk

-- 
You received this message because you are subscribed 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/rrvqcs%24108g%241%40ciao.gmane.io.

[go-nuts] Re: Generics, please go away!

[wilk]

On 23-12-2020, Jeremy French wrote:
> I'd like to second the notion that the argument "if you don't like them,=20
> don't use them," is an invalid argument.  Anyone who's been in the game for=

> any length of time knows that more than we'd like, we're repairing someone=

> else's code, as opposed to writing our own from scratch.  If there is a bad=

> or confusing way to write Go code, then it will be written that way by=20
> some, and we'll all be forced to deal with it.

+1

It's really a killer feature of Go. I gave somes lessons, it's unique
that we can teach 100% of the language in few days.
With generics we'll need one day more !

-- 
wilk

-- 
You received this message because you are subscribed 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/rrvocl%244p4%242%40ciao.gmane.io.

[go-nuts] Re: Generics, please go away!

[wilk]

On 22-12-2020, Ian Lance Taylor wrote:
> On Tue, Dec 22, 2020 at 1:24 AM Markus Heukelom
> wrote:
>>
>> Why not issue a poll on generics, was this ever done? (I could've missed it, 
>> I  am only following Go ~2 years). While the community has a vote in 
>> accepting/rejecting the current generics proposal, the community was never 
>> (really) asked if generics is desired in the first place and especially what 
>> the scope of generics should be. Is that correct?
>
> I don't know of a poll specifically about generics.  But for the past
> several years we've done a Go community survey, and every year there
> is significant support for adding generics to the language.  For
> example, although the results of the 2020 survey haven't been
> assembled yet, you can see the results of the 2019 survey at
> https://blog.golang.org/survey2019-results.  In that survey when asked
> "Which critical language features do you need that are not available
> in Go?", 25% of the survey takers answered the question, and of those
> 79% mentioned generics.  

79% of 25% is really not a lot...

Errors was also cited but we've seen that even smallest change as `try`
was rejected.

I was one of them who wanted to improve err != nil, but finally after
looking and testing all the proposals i rejected all...

> Previous years also showed support for adding
> generics.  Of course this isn't definitive, since there was no clear
> way for people they say that do not want generics.  But it's also not
> definitive in a different direction, which is that by and large people
> who don't currently use Go didn't take the survey, and probably some
> of them would also want generics.
>
> So while Go is not and never has been a poll-driven language, I think
> it's reasonable to say that there is real support for adding generics.

The problem is not really to can use generics when we want. Of course
every body want generics when he need it.
The problem is how will be used/abused generics when it just add
complexity when it would not add now...

Since years i've only one time needed generics to convert a Python lib,
then finally found a better anwser...

However, i understand that sometimes it's really usefull. 

How to make sure that it's not abused ?

-- 
wilk

-- 
You received this message because you are subscribed 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/rrvo4o%244p4%241%40ciao.gmane.io.

[go-nuts] Re: Generics, please go away!

[wilk]

On 21-12-2020, Martin Hanson wrote:
> I have just suggested the same thing @Space A, before I read your message and 
> I agree fully!
>
> https://github.com/golang/go/issues/15292#issuecomment-749032046
>
> I strongly believe we need to fork Go if generics gets added and then let the 
> toy people have their new shiny things in Go while we rename Go into 
> something else and stay with Go 1. Then we need to have the first and most 
> important rule, that NOTHING new gets added to Go 1.
>
> Go definitely needs a fork if generics gets added!
>

It could be easy to fork Go and just forbid generics but you'll loose
all the libs that will use generics. And it's in libs that generics is
most usefull (like interfaces) !

I'm not so afraid of generics.
When i see the last draft, we can even says that we already have a form
of generics at method level with concept of interface since beginning.
When we use io.Reader, it's generic, we don't wait for a type.
The way generic are added it's not really generics like in
other langages, it's type parameters with constraints like with
interface with method. It's not really a new concept in Go.

We already can abuse of empty interface{}. It'll be the same with type
parameters, we could abuse of type 'any' but most of the time we'll use
type parameters with constraints, like interface with method and it'll
keep strong.

Sorry for my bad english, if somebody understand and could rewrite what
i mean ?

-- 
wilk

-- 
You received this message because you are subscribed 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/rrseie%249sm%241%40ciao.gmane.io.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[wilk]

On 21-08-2020, Russ Cox wrote:

> A few other people have raised concerns about not seeing the word interface
> and therefore not realizing "any" is an interface type and potentially
> getting confused. This is also a good consideration, but we already have
> many interface types that don't use the word interface, most notably the
> predefined type error, but also io.Reader, http.ResponseWriter, and so on.
> People learn early on that not all interface types say interface in the
> name. I don't expect that "any" will not be any harder to learn than the
> others.

Why not `anyer` then ?

-- 
Wilk

-- 
You received this message because you are subscribed 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/rhqca3%24e37%241%40ciao.gmane.io.

[go-nuts] Re: Share GOMODCACHE between unix users

[wilk]

On 19-08-2020, Marcin Romaszewicz wrote:
> --71f06b05ad3dc9f8
> Content-Type: text/plain; charset="UTF-8"
>
> I have many users building Go at my company, and instead of sharing the
> module cache on the filesystem, a much better approach is to use a caching
> module proxy, such as Athens (https://github.com/gomods/athens).
>
> See the documentation for the GOPROXY environment variable.

With an alternate GOPROXY the GOMODCACHE of each users are still filled isn'it ?

I've started an issue :
https://github.com/golang/go/issues/40895

-- 
William Dodé

-- 
You received this message because you are subscribed 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/rhjm1l%24b2d%241%40ciao.gmane.io.

[go-nuts] Share GOMODCACHE between unix users

[wilk]

Hi,

I would like to have a global GOMODCACHE for all unix users, or a group of
users to gain space and speed. I trust all the users.

Using the same GOMODCACHE for all users doesn't works, the perms are only
writable by the user running the build.

Is there a workaround ? Could it be a feature ?

Thanks

-- 
William

-- 
You received this message because you are subscribed 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/rhim4i%24u2p%241%40ciao.gmane.io.

[go-nuts] xerrors and stack trace

[wilk]

Hi,

I was using xerrors, and now with go1.13 i wanted to remove this
dependency since I read on github.com/golang/xerrors
This repository holds the transition packages for the new Go 1.13
error values.

But unfortunately there are no more stack trace in go1.13

So xerrors is not more a transition package for Go 1.13 ?

Will the stack trace of xerrors become part of go1.14 ? Will xerrors
going to be maintained if stack trace are not going in go1.14 ?

Thanks

-- 
Wilk

-- 
You received this message because you are subscribed 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/qn88c4%2475lo%241%40blaine.gmane.org.

[go-nuts] Re: Go Module Mirror and Checksum Database in Beta!

[wilk]

On 31-05-2019, Amnon Baron Cohen wrote:
> --=_Part_967_922323128.1559316498912
> Content-Type: multipart/alternative; 
>   boundary="=_Part_968_1050003518.1559316498912"
>
> --=_Part_968_1050003518.1559316498912
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> See https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md
>
> The current behavior is not ideal from a security point of view.
> So it is good that 1.13 is fixing this.
> And unless the fix is default, most users will not get the benefit.

I see, thanks.

Is there a way to test proxy.golang.org with go1.12 if we have private
dependencies ?

-- 
William Dodé

-- 
You received this message because you are subscribed 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/qcrl7s%243g0s%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go Module Mirror and Checksum Database in Beta!

[wilk]

On 30-05-2019, Katie Hockman wrote:

> The module mirror at proxy.golang.org serves the go command=E2=80=99s proxy
> protocol. The Go 1.13 development tree uses this mirror for all module
> downloads by default. See the go command documentation at tip
>
> for details. To make earlier versions of the go command use it (when in
> module mode), set GOPROXY=3Dhttps://proxy.golang.org.

Could you explain why this option will be default and not opt-in ?
It can break current workflow, for example with private repos.

Thanks

-- 
William Dodé

-- 
You received this message because you are subscribed 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/qcr9cj%2464gr%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interesting public commentary on Go...

[wilk]

On 23-05-2019, Sam Whited wrote:
> Thank you for writing your reply Ian. Since it's a rather long post I
> don't want to go through it point by point, but suffice it to say that I
> agree with most of what you've written. However, I also agree that Go is
> Google's language, and that in its current form this is a problem. I'm going 
> to talk about two related but distinct probles here:
>
> It's good to have strong central leadership, and I'm okay with that
> leadership being employed by Google. The problem is that the Go team
> doesn't always appear to be interested in listening to the rest of the
> community. We saw this when the modules proposal was created and rushed
> out without adequate community feedback; after the push back against
> that the Go team promised to do better, but they're still putting out
> proposals with little to no opportunity to make significant changes (eg.
> the package sum proposal which was put out, and then almost immediately
> merged, made into a release, and then made the default behavior).

I don't think the Go team doesn't listen to the community about modules,
quite the opposite technicaly speaking.

But i share your concern about proxy.golang.org being the default.
Because of privacy but also because it immediatly break private repos
and some country.

I believe it could be just fine if it's opt-in, specially that in the
alpha stage...

And thanks Ian for your writing. I'm every day surprise to see how a
language can fit at the same time a big compagny and an independant 
developer ! scaling is that !

-- 
Wilk

-- 
You received this message because you are subscribed 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/qc6v1n%24jpm%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go if else syntax .. suggested replacement

[wilk]

On 24-04-2019, lgod...@gmail.com wrote:
> --=_Part_538_706677508.1556067911841
> Content-Type: multipart/alternative; 
>   boundary="=_Part_539_1965717614.1556067911841"
>
> --=_Part_539_1965717614.1556067911841
> Content-Type: text/plain; charset="UTF-8"
>
> It sure would be nice if Go syntax allowed programmers to replace 

I suggest you to use switch case...

-- 


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: goimports performance degrades in go module

[wilk]

On 08-11-2018, 'Ian Cottrell' via golang-nuts wrote:
> --ea8501057a283d99
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> Could you try the module aware fork of goimports
> https://github.com/heschik/goimports and let us know if it works and 
> is
> acceptable speed wise?
> We are not merging it back yet because we think it may be slower for 
> non
> module users, and we want some more confidence that it is a drop in
> replacement, but it should work.

I felt again in the trap of using a module name without dot (for quick 
tests)!  Even if I know that it's highly recommended to use a module 
name with a dot (there are others issues with this)
It doesn't works with your fork, it works with golang.org/x/tools/

Can we say now officially that a dot in a module name is mandatory ?

>
> Thanks
> Ian
>
> On Wed, Nov 7, 2018 at 7:43 PM Joseph Lorenzini  wrote:
>
>>
>>
>> Hi all,
>>
>> If have a go.mod, goimports takes 30 seconds to run. If I remove the
>> go.mod, then goimports takes half a second to run. Is this expected? Is
>> goimports trying to do something with the packages found in go.mod? Is
>> there a way to configure goimports so it ignores go.mod?
>>
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>


-- 
William

-- 
You received this message because you are subscribed 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] go 1.11 and XP

[wilk]

Hi,

Go 1.11 is not more compatible with Windows XP, but is it the compilator 
or the executable or both ?

I just tried an app (build on linux) and doesn't see any failure...

-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Link: Getting specific about generics

[wilk]

On 02-09-2018, Tristan Colgate wrote:
> --633c2e0574df037c
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> It's a great read, clarified stuff for me. An approach that embraces
> interfaces feels preferable to me.

+1


-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Is the go 1.11 godoc tool 'module-aware'?

[wilk]

It could be fine to start a wiki page to list the tools and ide 
(not)ready for modules with the linked issues.

In https://github.com/golang/go/wiki/Modules or a new page ?

On 29-08-2018, Paul Jolly wrote:
> --50127c057491b176
> Content-Type: text/plain; charset="UTF-8"
>
> Please see https://github.com/golang/gddo/issues/567
>
> On Tue, 28 Aug 2018, 18:59 Justin Israel,  wrote:
>
>> I've been trying out converting some of our internal projects to go 1.11
>> using modules instead of glide. We have a build system that provides the
>> ability to generate html docs via "godoc" and I am wondering if godoc has
>> been made "module-aware" in go 1.11?
>>
>> My particular project is using the migration approach of setting "v3" at
>> in the go.mod, and in all import paths within the project. But it seems
>> godoc is not happy about this:
>>
>> godoc -links=0 -html domain.com/group/project/v3/lib/foo
>>
>> 2018/08/29 11:52:12 error while importing build package: cannot find package 
>> "domain.com/group/project/v3/lib/foo" in any of:
>> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo (from 
>> $GOROOT)
>> /usr/home/justin/src/go/src/domain.com/group/project/v3/lib/foo 
>> (from $GOPATH)
>> 2018/08/29 11:52:12 cannot find package "." in:
>> /src/domain.com/group/project/v3/lib/foo
>>
>>
>> It seems to only care about the filesystem structure and not the module 
>> import path naming?
>>
>>
>> Justin
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>


-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Local cache of dependencies

[wilk]

On 22-08-2018, Conor Hackett wrote:
> --=_Part_816_169128197.1534976743243
> Content-Type: multipart/alternative; 
>   boundary="=_Part_817_1168505210.1534976743243"
>
> --=_Part_817_1168505210.1534976743243
> Content-Type: text/plain; charset="UTF-8"
>
> Hey Guys,
>
> So, adding your "vendor" directory to SCM is a contentious topic at best.
>
> I personally would rather not vendor the dependencies but I do need to keep 
> the required code in my control and I consider third party repos out of my 
> control.
>
> Similar to how maven works (and others I am sure), is there some tooling 
> that will enable me to cache/store/save third party dependencies on my 
> local machine/server etc in order to

With go module when you go get a module it cache it in $GOPATH/pkg/mod
Maybe you just need to backup this directory.


-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: vgo and handling major versions

[wilk]

On 26-02-2018, Kaveh Shahbazian wrote:

> It would be nice if vgo could handle something like (in .mod files) 
> `pkg 
>>1.2.1 branch-name-*` and the `*` part could be a major number and the 
> `1.2.1` is tag. The `branch-name-*` part is a pattern for branch name.

If I understand what you mean, I would resolv this with replace 
directive of go.mod to a clone of the branch. This clone could be 
a subrepositories of the dvcs to can keep everything.

-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: vgo with package path without dot

[wilk]

On 24-02-2018, flicaf...@gmail.com wrote:
> --=_Part_9366_348433021.1519468400573
> Content-Type: multipart/alternative; 
>   boundary="=_Part_9367_868487623.1519468400573"
>
> --=_Part_9367_868487623.1519468400573
> Content-Type: text/plain; charset="UTF-8"
>
> Vgo implements a package manager which is suppose to download dependencies 
> from some remote host.

I tried this as a workaround :

require "mylib" v0.1.0
replace "mylib" v0.1.0 => "../mylib"

But it doesn't work either.

I see your point, you're right, it's evident. I just don't use that 
build also fetch !

Anyway the more I think the more I see that it will give more 
possibilities, with vgo proxy and so on...

I created an issue to put it in the FAQ maybe.

https://github.com/golang/go/issues/24100

thanks

-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: vgo with package path without dot

[wilk]

On 24-02-2018, Amnon Baron Cohen wrote:
> --=_Part_9094_478136164.1519461749739
> Content-Type: multipart/alternative; 
>   boundary="=_Part_9095_482511421.1519461749739"
>
> --=_Part_9095_482511421.1519461749739
> Content-Type: text/plain; charset="UTF-8"
>
>
>
> On Friday, 23 February 2018 
>>
>>
>> I work with GOPATH per project. 
>>
>> Then I use to give them a one word path directly under src: 
>>
>> $GOPATH/src/myapp 
>>
>>
> Go is a highly opinionated language assumes that you lay out your code as 
> described in https://golang.org/doc/code.html
> If you decide to do things differently (by having 'simpler' paths 
> which do not correspond to the VCS location of your code on the net), 
> then you end up having to fight the go tools, rather than have them 
> work for you.
>

I don't think it's not recommended :

https://golang.org/doc/install#testing

Next, make the directory src/hello inside your workspace, and in that 
directory create a file named hello.go

$ cd $HOME/go/src/hello
$ go build

https://blog.golang.org/organizing-go-code
If you don't use a hosted source repository, choose some unique prefix 
such as a domain, company, or project name. As an example, the import 
path of all Google's internal Go code starts with the string "google".


-- 
William

-- 
You received this message because you are subscribed 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] vgo with package path without dot

[wilk]

Hi,

I work with GOPATH per project.

Then I use to give them a one word path directly under src:

$GOPATH/src/myapp

But I found that it doesn't work with vgo. It looks at 
/usr/local/go/src/ instead of my GOPATH.
The same when i use replace with a clone of a libs.

If there is a dot in the package name it works

$GOPATH/src/my.domain/myapp/

Should i submit an issue or shoud i forget quickly this bad practice ?

-- 
William

-- 
You received this message because you are subscribed 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] nginx and upstream prematurely closed connection while reading upstream

[wilk]

Hi,

I'm experiencing a lot of log in nginx :
upstream prematurely closed connection while reading upstream

Looking in my code it's because I added 

w.Header().Set("content-length", strconv.Itoa(len(w.Body.Bytes(
If i remove it, no more logs and my clients are happy again

I use an httptest.ResponseRecorder as a response buffer.

then write the headers (content type and cookies), write the code and 
write the body wrt.Write(w.Body.Bytes()). Nothing special, if i look 
with curl the content-lenght seems to be ok.

I don't see where i did a mistake, and it's difficult to find because 
i cannot reproduce it localy.

Thanks

-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] Mutagen - A unique file sync utility in Go inspired by Unison

[wilk]

On 05-01-2017, Jacob Howard wrote:
> --=_Part_50_803652314.1483655759799
> Content-Type: multipart/alternative; 
>   boundary="=_Part_51_771736522.1483655759799"
>
> --=_Part_51_771736522.1483655759799
> Content-Type: text/plain; charset=UTF-8
>
> Syncthing's transfer model is a bit different with it's block-exchange 
> protocol, so it's a bit difficult to compare the exact behavior.  For most 
> use cases, I think you'd see comparable performance in terms of data 
> transfer required for change propagation, though Mutagen could perform a 
> few additional optimizations that it doesn't currently do, e.g. optimizing 
> rsync block size based on file size, but these would be very marginal gains.

By deduplication, i mean on differents files.
If differents files share a common part, this part will be transfered 
two times ?

>
> -Jacob
>
> On Thursday, January 5, 2017 at 7:13:06 PM UTC+2, wilk wrote:
>>
>> On 05-01-2017, Shawn Milochik wrote: 
>> > --94eb2c1a09e43b9d8205455b0873 
>> > Content-Type: text/plain; charset=UTF-8 
>> > 
>> > I really like the idea of what you have here. I'm currently using 
>> SyncThing 
>> > for this purpose. SyncThing seems to fit all your requirements with the 
>> > exception of only needing to be installed on one of the machines. 
>> However, 
>> > in return SyncThing allows you to select which folders are shared from 
>> each 
>> > machine to each other machine, making it really useful for sharing only 
>> a 
>> > subset of your data with other people. https://syncthing.net/ 
>>
>> The bonus of syncthing is also deduplication on whole files right ? 
>> Mutagen will do it also ? 
>>
>>
>>
>> -- 
>> William 
>>
>>
>


-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] Mutagen - A unique file sync utility in Go inspired by Unison

[wilk]

On 05-01-2017, Shawn Milochik wrote:
> --94eb2c1a09e43b9d8205455b0873
> Content-Type: text/plain; charset=UTF-8
>
> I really like the idea of what you have here. I'm currently using SyncThing
> for this purpose. SyncThing seems to fit all your requirements with the
> exception of only needing to be installed on one of the machines. However,
> in return SyncThing allows you to select which folders are shared from each
> machine to each other machine, making it really useful for sharing only a
> subset of your data with other people. https://syncthing.net/

The bonus of syncthing is also deduplication on whole files right ?
Mutagen will do it also ?



-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Deleting the /r/golang subreddit

[wilk]

On 25-11-2016, Konstantin Khomoutov wrote:
> On Thu, 24 Nov 2016 23:59:18 -0800 (PST)
> Ainar Garipov  wrote:
>
>> Please no. Google Groups is awful, Reddit's /r/golang is where I get
>> most of my Go news. I don't want to sift through a forum with no
>> voting system, and awful and slow overly-JS-ed design.
>
> On a side note I continue to wonder why people struggle with crappy web
> stuff when they can just subscribe to this mailing list and get mail
> from it into their mailbox, and read/write mails there using convenient
> mail reader (with proper threads, searching tagging custom mail folders
> and so on).
>
> Google Groups is just a web front-end for those dirt-old but trusty
> mailing lists of the 90's ;-)
>

Right, Reddit is also a black hole of productivity !

It could be fine to have a comp.lang.go.announce like in python, open to 
external gophers.


-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Deleting the /r/golang subreddit

[wilk]

On 25-11-2016, Linus Drumbler wrote:
> --=_Part_1058_1225835188.1480057636020
> Content-Type: multipart/alternative; 
>   boundary="=_Part_1059_1164393322.1480057636021"
>
> --=_Part_1059_1164393322.1480057636021
> Content-Type: text/plain; charset=UTF-8
>
> Moderators of a subreddit can choose to have "restricted submissions", so 
> that only approved submitters can post. This will fill the purpose of 
> disabling new content while still keeping the old content available.

+1

-- 
William

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: MSACCESS with Go ?

[wilk]

On 07-10-2016, Konstantin Khomoutov wrote:
> On Thu, 6 Oct 2016 20:24:47 + (UTC)
> wilk <w...@flibuste.net> wrote:
>
>> I know... but i must access to MSACCESS database. I would like to use
>> Go instead of Python.
>> I found alexbrainman/odbc and it works. I found some litle issues
>> that I submited to the project but I think I can workaround.
>> 
>> Before I continue to dig, are there others Gophers using MSACCESS ?
>> In production ?
>
> I'm not doig this, but I'm pretty sure using its native drivers through
> ODBC is pretty much the most sensible way to go about dealing with your
> task.  And that alexbrainman/odbc driver is of good quality and is well
> maintained.

Fine, I'm confident of the quality of this driver, I'll continue to try.

>
> Well, in theory, you could take another route and write some low-level
> glue code in C++ to use the OLE DB "Jet database" drivers, and then
> make use of that code in your Go project (on Windows, you could avoid
> using `cgo` by building a DLL with your glue code and accessing it from
> Go using the same way alexbrainman/odbc deals with ODBC DLLs).
> I'm afraid this is too much work for too little gain though.
> So I'd go with ODBC untill you encounter some major unfixable roadblock
> going that way.
>
> It could also be possible to use the MS Jet DLL directly but I'm again
> afraid that would be even more work that accessing it through OLE DB
> layer.

I'm happy that there are other possibilities.
But I'm affraid to be alone using MSACCESS with Go. Even if I understand 
that nobody want to invest in this.

-- 
William

-- 
You received this message because you are subscribed 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.