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

[Henrik Johansson]

Who said anything about gold standards?
This is about generics going away and I would argue that many if not all
computer languages that have generics also have a user base that is
overwhelmingly in favor of it compared to it not existing. Perhaps another
flavor of generics would be better but being without it would be worse.

On Sat, 26 Dec 2020, 16:13 Jeremy French,  wrote:

> If Java and C++ were the perfection of computer language evolution, then
> there would be no need for Go. Using your predecessors as the gold standard
> makes no sense, because if they were, then no other iteration would be
> necessary. We wouldn't be having this discussion, because there would be no
> Go.
>
> Java and C++ both suffer from being complex enough that both inital
> development and especially further maintenance of code written in those
> languages is slower than it should be. This was one of the main drivers in
> creating Go in the first place (as I understand it).
>
> Trying to make all programming languages identical means that all but one
> of them is redundant.
>
> On Fri, Dec 25, 2020, 11:49 AM Henrik Johansson 
> wrote:
>
>> Ok maybe this thread has gone on too long.
>> Both Java and C++ has benefited greatly from generics and most of their
>> respective communities wouldn't want them gone. I am pretty sure that's
>> what will happen with Go as well. Can we leave it now before we go from
>> "corruption" to whatever hyperbole is next?
>>
>> On Fri, 25 Dec 2020, 14:10 redsto...@gmail.com, 
>> wrote:
>>
>>> Yes, I agree with you. I use go for more than 3 years. The language is
>>> simple and elegant. But generics will destroy this. Generics bring a lot of
>>> complexity, make language seems ugly with only a few benifit.  They say you
>>> can ignore it. Infact you can not. This language is on the way of
>>> corruption.
>>>
>>> On Monday, December 21, 2020 at 3:38:54 AM UTC+8 Martin Hanson wrote:
>>>
>>>> I think people who want generics added to Go should go and program in
>>>> Java or C++.
>>>>
>>>> Adding generics to Go will ruin the beautiful simplicity of the
>>>> language and I haven't found a single example in which adding generics to
>>>> Go pays off.
>>>>
>>>> Even with the examples of having two almost identical functions reverse
>>>> some list, one of ints and one of strings, seriously!? We already have tons
>>>> and tons of open source reusable code that covers all use cases which
>>>> people complain about.
>>>>
>>>> Go was designed without generics purposefully from the start and Go is
>>>> fine just the way it is.
>>>>
>>>> Adding generics means that we're opening the door to the beginning of
>>>> bloating Go with all the crap that Java, C++ and all the other complex
>>>> languages has gotten over the years, and Go was designed specifically
>>>> without that clutter. So we add generics, then what? Classes?
>>>>
>>>> Adding generics to Go ruins that beautiful simplicity that went into
>>>> the design and the added complexity just isn't worth it! The standard
>>>> library have managed just fine without generics and so have we!
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> 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/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/LEEuJPOg0oo/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAKOF6940G995GFLoNp_z1Hsx2G_2e%2Bibs7xAqkTne0RAJUL5fw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAKOF6940G995GFLoNp_z1Hsx2G_2e%2Bibs7xAqkTne0RAJUL5fw%40mail.gmail.com?utm_medium=email_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/CAKOF697Q2SaL-grQiL81gUkTztjJc_cF5r3JKhjO%2B1FPtAitAw%40mail.gmail.com.

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

[Henrik Johansson]

Ok maybe this thread has gone on too long.
Both Java and C++ has benefited greatly from generics and most of their
respective communities wouldn't want them gone. I am pretty sure that's
what will happen with Go as well. Can we leave it now before we go from
"corruption" to whatever hyperbole is next?

On Fri, 25 Dec 2020, 14:10 redsto...@gmail.com, 
wrote:

> Yes, I agree with you. I use go for more than 3 years. The language is
> simple and elegant. But generics will destroy this. Generics bring a lot of
> complexity, make language seems ugly with only a few benifit.  They say you
> can ignore it. Infact you can not. This language is on the way of
> corruption.
>
> On Monday, December 21, 2020 at 3:38:54 AM UTC+8 Martin Hanson wrote:
>
>> I think people who want generics added to Go should go and program in
>> Java or C++.
>>
>> Adding generics to Go will ruin the beautiful simplicity of the language
>> and I haven't found a single example in which adding generics to Go pays
>> off.
>>
>> Even with the examples of having two almost identical functions reverse
>> some list, one of ints and one of strings, seriously!? We already have tons
>> and tons of open source reusable code that covers all use cases which
>> people complain about.
>>
>> Go was designed without generics purposefully from the start and Go is
>> fine just the way it is.
>>
>> Adding generics means that we're opening the door to the beginning of
>> bloating Go with all the crap that Java, C++ and all the other complex
>> languages has gotten over the years, and Go was designed specifically
>> without that clutter. So we add generics, then what? Classes?
>>
>> Adding generics to Go ruins that beautiful simplicity that went into the
>> design and the added complexity just isn't worth it! The standard library
>> have managed just fine without generics and so have we!
>>
> --
> You received this message because you are subscribed to the Google 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/7c3e4e9f-4553-413b-8bdb-57d316ad030cn%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/CAKOF6940G995GFLoNp_z1Hsx2G_2e%2Bibs7xAqkTne0RAJUL5fw%40mail.gmail.com.

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

[Henrik Johansson]

Why will interfaces be more idiomatic once generics lands? It remains to be
seen I guess but I could very well see the other way become the idiom.

On Wed, 23 Dec 2020, 21:20 wilk,  wrote:

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

-- 
You received this message because you are subscribed to the Google 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/CAKOF694%2B7VE_H2JqNZuT1iHZhntAdkNxqwkntsOOTtbQKUEKfQ%40mail.gmail.com.

Re: [go-nuts] mytex.RWLock recursive read lock

[Henrik Johansson]

This is funny, why isn't there a panic in this case? It clearly "works" as
in it doesn't deadlock or panics assuming a write lock isn't somehow mixed
incorrectly.


On Tue, Sep 22, 2020 at 3:56 PM 'Bryan C. Mills' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Note that a lock on a sync.Mutex or sync.RWMutex is *not* held by a
> specific goroutine: it can be locked by one goroutine, then communicated by
> some other means (such as being sent on a channel) and unlocked on a
> *different* goroutine. (See also https://golang.org/issue/9201.)
>
> That is: these locks *cannot* be reentrant because they do not contain
> goroutine-specific metadata.
>
> I read through the docs for this type again, and noticed that while the
> documentation for the Unlock method seems very clear on this point, the
> documentation for the type itself is not. (I filed
> https://golang.org/issue/41555, for which you are welcome to contribute
> <https://golang.org/doc/contribute.html> a fix!)
>
> On Monday, September 21, 2020 at 8:26:46 AM UTC-4
> axel.wa...@googlemail.com wrote:
>
>> FTR, I still don't think the docs *are* ambiguous. The authoritative part
>> is
>>
>> If a goroutine holds a RWMutex for reading and another goroutine might
>>> call Lock, no goroutine should expect to be able to acquire a read lock
>>> until the initial read lock is released.
>>
>>
>> The rest is just additional explanation. This sentence alone is already
>> sufficient to define the behavior.
>>
>> On Mon, Sep 21, 2020 at 2:14 PM Axel Wagner 
>> wrote:
>>
>>> On Mon, Sep 21, 2020 at 2:06 PM Henrik Johansson 
>>> wrote:
>>>
>>>> Ambiguous docs however aren't generally good in any way. This came up
>>>> as a consequence of real code being changed by a new very skilled developer
>>>> and there was quite a bit discussion that could have been avoided with
>>>> clearer docs.
>>>>
>>>
>>> I think it would be useful to be more explicit about the use-case then.
>>> As I said, I can't really fathom a situation where you'd *want* to do that
>>> and if you don't want it, I can't imagine how it would matter whether you
>>> can.
>>>
>>>
>>>>
>>>> We have sorted the issue I mostly wanted to confirm my suspicion wrt
>>>> nested read locks.
>>>>
>>>> On Mon, 21 Sep 2020, 13:31 Axel Wagner, 
>>>> wrote:
>>>>
>>>>> To elaborate a bit: You are correct in that there is a slight
>>>>> syntactic ambiguity whether "this prohibits" refers to the entire sentence
>>>>> ("if another goroutine might call Lock, then a second RLock might not be
>>>>> acquired"), or only to the second half. I would argue the rest of the
>>>>> section makes it clear that the second version is intended - "a goroutine
>>>>> can not expect a second RLock to be acquired. This prohibits…".
>>>>>
>>>>> But yes, it certainly can be argued that the ambiguity hides the
>>>>> possibility of nested RLocks when no other goroutine calls Lock. But even
>>>>> if then: Given that this would not be useful (an RLock without a 
>>>>> concurrent
>>>>> Lock is functionally a no-op, AIUI), but *can* lead to incorrect code if
>>>>> applied improperly, that possibility doesn't seem worthwhile to advertise
>>>>> further.
>>>>>
>>>>> So even if the docs are ambiguous, that hardly seems a problem.
>>>>>
>>>>> On Mon, Sep 21, 2020 at 12:58 PM Axel Wagner <
>>>>> axel.wa...@googlemail.com> wrote:
>>>>>
>>>>>> It only says that's excluded *if* you can have a concurrent Lock call.
>>>>>>
>>>>>> On Mon, Sep 21, 2020 at 12:48 PM Henrik Johansson 
>>>>>> wrote:
>>>>>>
>>>>>>> Yes that's the canonical deadlock but doesn't the docs say
>>>>>>>
>>>>>>> "In particular, this prohibits recursive read locking"
>>>>>>>
>>>>>>> which it doesn't unless you mix reads and writes.
>>>>>>>
>>>>>>> I get that it's not advisable but it's not prohibited either or
>>>>>>> there would be a panic or something.
>>>>>>>
>>>>>>> On Mon, 21 Sep 2020, 12:30 Axel Wagner, 
>>>>>>> wrote:
>>>>&g

Re: [go-nuts] mytex.RWLock recursive read lock

[Henrik Johansson]

A lot can be argued ;)

Ambiguous docs however aren't generally good in any way. This came up as a
consequence of real code being changed by a new very skilled developer and
there was quite a bit discussion that could have been avoided with clearer
docs.

We have sorted the issue I mostly wanted to confirm my suspicion wrt nested
read locks.

On Mon, 21 Sep 2020, 13:31 Axel Wagner, 
wrote:

> To elaborate a bit: You are correct in that there is a slight syntactic
> ambiguity whether "this prohibits" refers to the entire sentence ("if
> another goroutine might call Lock, then a second RLock might not be
> acquired"), or only to the second half. I would argue the rest of the
> section makes it clear that the second version is intended - "a goroutine
> can not expect a second RLock to be acquired. This prohibits…".
>
> But yes, it certainly can be argued that the ambiguity hides the
> possibility of nested RLocks when no other goroutine calls Lock. But even
> if then: Given that this would not be useful (an RLock without a concurrent
> Lock is functionally a no-op, AIUI), but *can* lead to incorrect code if
> applied improperly, that possibility doesn't seem worthwhile to advertise
> further.
>
> So even if the docs are ambiguous, that hardly seems a problem.
>
> On Mon, Sep 21, 2020 at 12:58 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> It only says that's excluded *if* you can have a concurrent Lock call.
>>
>> On Mon, Sep 21, 2020 at 12:48 PM Henrik Johansson 
>> wrote:
>>
>>> Yes that's the canonical deadlock but doesn't the docs say
>>>
>>> "In particular, this prohibits recursive read locking"
>>>
>>> which it doesn't unless you mix reads and writes.
>>>
>>> I get that it's not advisable but it's not prohibited either or there
>>> would be a panic or something.
>>>
>>> On Mon, 21 Sep 2020, 12:30 Axel Wagner, 
>>> wrote:
>>>
>>>> (Note, FWIW, that in particular no write locks need to be *held*. It's
>>>> enough for Lock to be *called*, it doesn't have to have returned yet)
>>>>
>>>> On Mon, Sep 21, 2020 at 12:29 PM Axel Wagner <
>>>> axel.wagner...@googlemail.com> wrote:
>>>>
>>>>> I feel like the docs are pretty precise in what they say and why.
>>>>>
>>>>> a blocked Lock call excludes new readers from acquiring the lock.
>>>>>
>>>>>
>>>>> This means, the following could happen:
>>>>> Goroutine 1 calls RLock, acquires a Read-Lock
>>>>> Goroutine 2 calls Lock, blocking
>>>>> Goroutine 1 calls RLock again, blocking (as no new read locks can be
>>>>> acquired while GR 2 is blocked).
>>>>> Thus, you get a deadlock.
>>>>>
>>>>> It also has a conditional on the section
>>>>>
>>>>> If a goroutine holds a RWMutex for reading and another goroutine might
>>>>>> call Lock […]
>>>>>
>>>>>
>>>>> So if you know that no other goroutine might call Lock concurrently,
>>>>> then yes, you can call RLock twice. I can't really imagine a setting where
>>>>> you'd need an RWMutex and have that assurance and need recursive read
>>>>> locks. But there might be one.
>>>>>
>>>>> On Mon, Sep 21, 2020 at 12:16 PM Henrik Johansson <
>>>>> dahankz...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> https://golang.org/pkg/sync/#RWMutex
>>>>>>
>>>>>> Holds that this prohibits recursive read locks but why would it?
>>>>>> I understand that deadlocks can happen in case write locks are held
>>>>>> in between the read locks
>>>>>> but why can't a goroutine issue several RLock calls?
>>>>>>
>>>>>> It does actually work in the playground.
>>>>>> https://play.golang.org/p/nOehJaeikxA
>>>>>> Is this simply a recommendation or should the docs be updated to
>>>>>> clarify what this means?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> 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/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/golang-nuts/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%40mail.gmail.com?utm_medium=email_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/CAKOF69666gwHakAoh3MsNZAFmgZFFvSTCLs9AT%2BG91ZS0H615w%40mail.gmail.com.

Re: [go-nuts] mytex.RWLock recursive read lock

[Henrik Johansson]

Yes that's the canonical deadlock but doesn't the docs say

"In particular, this prohibits recursive read locking"

which it doesn't unless you mix reads and writes.

I get that it's not advisable but it's not prohibited either or there would
be a panic or something.

On Mon, 21 Sep 2020, 12:30 Axel Wagner, 
wrote:

> (Note, FWIW, that in particular no write locks need to be *held*. It's
> enough for Lock to be *called*, it doesn't have to have returned yet)
>
> On Mon, Sep 21, 2020 at 12:29 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> I feel like the docs are pretty precise in what they say and why.
>>
>> a blocked Lock call excludes new readers from acquiring the lock.
>>
>>
>> This means, the following could happen:
>> Goroutine 1 calls RLock, acquires a Read-Lock
>> Goroutine 2 calls Lock, blocking
>> Goroutine 1 calls RLock again, blocking (as no new read locks can be
>> acquired while GR 2 is blocked).
>> Thus, you get a deadlock.
>>
>> It also has a conditional on the section
>>
>> If a goroutine holds a RWMutex for reading and another goroutine might
>>> call Lock […]
>>
>>
>> So if you know that no other goroutine might call Lock concurrently, then
>> yes, you can call RLock twice. I can't really imagine a setting where you'd
>> need an RWMutex and have that assurance and need recursive read locks. But
>> there might be one.
>>
>> On Mon, Sep 21, 2020 at 12:16 PM Henrik Johansson 
>> wrote:
>>
>>>
>>> https://golang.org/pkg/sync/#RWMutex
>>>
>>> Holds that this prohibits recursive read locks but why would it?
>>> I understand that deadlocks can happen in case write locks are held in
>>> between the read locks
>>> but why can't a goroutine issue several RLock calls?
>>>
>>> It does actually work in the playground.
>>> https://play.golang.org/p/nOehJaeikxA
>>> Is this simply a recommendation or should the docs be updated to clarify
>>> what this means?
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> 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/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/golang-nuts/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%40mail.gmail.com?utm_medium=email_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/CAKOF694kPWH2_SA%2BE3X9bAc37LzQbCs-CtAecT8gvOmY%3DvM5rg%40mail.gmail.com.

[go-nuts] mytex.RWLock recursive read lock

[Henrik Johansson]

https://golang.org/pkg/sync/#RWMutex

Holds that this prohibits recursive read locks but why would it?
I understand that deadlocks can happen in case write locks are held in
between the read locks
but why can't a goroutine issue several RLock calls?

It does actually work in the playground.
https://play.golang.org/p/nOehJaeikxA
Is this simply a recommendation or should the docs be updated to clarify
what this means?

-- 
You received this message because you are subscribed to the Google 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/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%40mail.gmail.com.

Re: [go-nuts] JMX Call with non-HTTP

[Henrik Johansson]

The Jolokia solution is quite neat if you can control the running JVM since
that bridge then runs inside the same JVM as an agent.
Many servers and services offer to configure the command line for this and
other similar purposes.

On Mon, Sep 14, 2020 at 9:05 PM Robert Engels  wrote:

> Search for Java RMI-IIOP.
>
> On Sep 14, 2020, at 2:04 PM, Robert Engels  wrote:
>
> 
> You need a bridge. RMI requires Java. if you use a subset you can use
> Corba/IIOP clients.
>
> On Sep 14, 2020, at 11:11 AM, Henrik Johansson 
> wrote:
>
> 
> Newrelic has some tools for this but I think they require agents installed
> in the Java side.
>
> I think you are better off going for the Jolokia solution but perhaps
> there is something you can use from Newrelic.
>
> On Mon, 14 Sep 2020, 17:52 Venkata Madhusudhan Rao V, 
> wrote:
>
>> Hi All,
>> I have a java-based application with JMX enabled. I was able to remotely
>> connected to the java-based application from JConsole using jmx url
>> (service:jmx:rmi:///jndi/rmi://localhost:/jmxrmi).
>> Now, I want to connect from Go-client to capture the metrics.
>> I looked at *Jolokia JMX/HTTP wrapper for Golang*, but it uses http
>> protocol to get connect. Is there any library available in GO to get
>> connected for the provided JMX url?
>>
>> Thanks & Regards
>> Venkata Madhu
>>
>> --
>> You received this message because you are subscribed to the Google 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/ed421a0e-6a0c-410e-9e3a-aff7c2e5030cn%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/ed421a0e-6a0c-410e-9e3a-aff7c2e5030cn%40googlegroups.com?utm_medium=email_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/CAKOF697xwfKTCkLmyL0TRjAUE9sSPn9P3LyzHzEVg6N6Y8_Gmg%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAKOF697xwfKTCkLmyL0TRjAUE9sSPn9P3LyzHzEVg6N6Y8_Gmg%40mail.gmail.com?utm_medium=email_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/C763C513-6439-4B40-942B-0831CC10D964%40ix.netcom.com
> <https://groups.google.com/d/msgid/golang-nuts/C763C513-6439-4B40-942B-0831CC10D964%40ix.netcom.com?utm_medium=email_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/CAKOF695Y4Tcfnkp5TSvBaUDJUkC3YP0yJMbQRRk2GngrOo%3D7AQ%40mail.gmail.com.

Re: [go-nuts] JMX Call with non-HTTP

[Henrik Johansson]

Newrelic has some tools for this but I think they require agents installed
in the Java side.

I think you are better off going for the Jolokia solution but perhaps there
is something you can use from Newrelic.

On Mon, 14 Sep 2020, 17:52 Venkata Madhusudhan Rao V, 
wrote:

> Hi All,
> I have a java-based application with JMX enabled. I was able to remotely
> connected to the java-based application from JConsole using jmx url
> (service:jmx:rmi:///jndi/rmi://localhost:/jmxrmi).
> Now, I want to connect from Go-client to capture the metrics.
> I looked at *Jolokia JMX/HTTP wrapper for Golang*, but it uses http
> protocol to get connect. Is there any library available in GO to get
> connected for the provided JMX url?
>
> Thanks & Regards
> Venkata Madhu
>
> --
> You received this message because you are subscribed to the Google 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/ed421a0e-6a0c-410e-9e3a-aff7c2e5030cn%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/CAKOF697xwfKTCkLmyL0TRjAUE9sSPn9P3LyzHzEVg6N6Y8_Gmg%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Henrik Johansson]

This is good. I have been reaching for a consistency check and this just
may be it.

On Thu, Jul 16, 2020 at 12:04 AM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> > And the use of [ ] in map is more semantically associated with its
> > conventional use as an element accessor in arrays / slices, not with
> > some more general kind of type parameter.
>
> The [] syntax can be viewed as an indexing operation perfectly well in
> the context of generics; a generic function or type is a map of
> implementations or types and so the [] syntax is a type index into that
> map, just as map[T1]T2 is a type index into the builtin generic map
> type. This is not mental stretch.
>
>
> --
> You received this message because you are subscribed to the Google 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/abe84ff5abefe2815137bea9cb83eb9e8d5fdafb.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/CAKOF696MO7RsR7kheXV4pKzSV4HQ7cGrAhH-YaC-KedQPWxx7g%40mail.gmail.com.

Re: [go-nuts] Re: Build management mechanism for go lang

[Henrik Johansson]

I usually use make for that in combination with Goreleaser
https://github.com/goreleaser/goreleaser/ .


On Wed, May 27, 2020 at 7:18 AM Chashika Weerathunga <
chashikajw...@gmail.com> wrote:

> go mod, go build fine. Also I want to pack(zip) a executable and other few
> directories into a folder. And also need to manage project version. In
> maven we can do tasks like this.  So I want to manage all the things in
> flexible way.
>
> On Wednesday, May 27, 2020 at 10:30:21 AM UTC+5:30, Chashika Weerathunga
> wrote:
>>
>> Instead of creating a bash file, is there any build management tool like
>> maven for go lang ? I want to do the version, dependency management and
>> also create build files etc.
>>
> --
> You received this message because you are subscribed to the Google 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/beb3c884-b76f-4af4-83ca-e2e27f5421db%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/CAKOF695Sm9v7CgQn7UNqyvRecrGC3DE-K0eNYRVz--rLtsbHPQ%40mail.gmail.com.

Re: [go-nuts] Why golang allocated memory space increases?

[Henrik Johansson]

Isn't this because of the GC tracking these and treating then as
effectively weak references to borrow a Java term?
If they are not pointers they are not tracked by the GC and I guess they
could all be removed at every scan?
Just guessing though, I haven't in any way checked it.

On Thu, Mar 26, 2020 at 11:34 AM Jakob Borg  wrote:

> On 26 Mar 2020, at 09:51, Tamás Gulácsi  wrote:
>
>
> sync.Pool MUST use pointers (*[]byte)
>
>
> I've seen this a lot but I confess I don't understand it. A []byte is
> essentially a fat pointer, what does it matter if we put that or a *[]byte
> into the pool? I understand that putting a []byte will result in an
> allocation of a new []byte, but probably the purpose is to preserve and
> avoid reallocating the backing array, which might be large.
>
> Is there something fundamental about the sync.Pool that means that a put
> *must* be zero-allocation for it to function? Likely the calling code
> around the puts/gets are not zero-allocation either.
>
> //jb
>
> --
> You received this message because you are subscribed to the Google 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/DB9E8E73-10B0-451B-BE66-13AF2930BB74%40kastelo.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/CAKOF6942VjqZ21b5ztW6wn6FTuk_MZDNz%2B3p1v2Njr_RAwRO4w%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

Absolutely but this has been said for a very long time already and we have
still to see it.

I agree GC's are getting better and better and who knows what the future
holds.

Until then I will gladly ignore the small loss of performance simply
becausenit rarely matter for the program's I write.

On Wed, 12 Feb 2020, 19:14 Jesper Louis Andersen, <
jesper.louis.ander...@gmail.com> wrote:

> If I may make an observation here:
>
> I think the vast majority of all programs benefit in productivity from a
> GC. In the sense, that the GC is an adequate solution at the least, and a
> more efficient solution in many cases, especially if you factor in
> development time. Managing memory manually, especially in concurrent
> settings, is going to take some attention to detail, and is likely to slow
> down how fast you can get a system working.
>
> What you are likely to be looking at here is good old selection bias. The
> problems that doesn't fare well under a current generation of GCs are
> likely to bubble to the top of syndication sites, simply for the fact that
> they are interesting outliers.
>
> My experience, over the last, say 20-40 years, is that GCs are slowly
> eating more and more of the cake. As they improve, it definitely converges
> toward more viability, not less. There will always be programs for which
> they fare badly. But as they are detected, so are GCs improved.
>
> On Wed, Feb 12, 2020 at 4:11 PM Henrik Johansson 
> wrote:
>
>> Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times
>> better so that particular example isn't really helping the GC case.
>>
>> I don't mind the GC myself but I hear the "GC is actually faster" often
>> and it seems not to be true in the wild although I am sure theoretical
>> cases can be envisioned.
>>
>> On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:
>>
>>> On 2020-02-12 14:02, Robert Engels wrote:
>>> > Most of that is because their codebase predates Java. There are more
>>> modern dbs
>>> > like Cassandra that are in Java. Certainly Hadoop is probably the
>>> largest
>>> > distributed database in the world and it’s written in Java.
>>>
>>> Bound to use more cpu cycles and memory than a c equivalent. Of course
>>> postgres
>>> is more capable.
>>>
>>>
>>> https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> 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/f388606c-7f52-78bc-f59c-776688114e4f%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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKOF6944bsaL%2Bfj4LBKapEk4O_cr5rs2wzBT%3DCsR1uBEZnxCsw%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

It's beside the point and you are wrong but please rerun in any setup you
want.

Anyway for "day job" I am fine with GC.

On Wed, 12 Feb 2020, 18:05 Robert Engels,  wrote:

> Note sure where you are getting that - their own report
> https://www.scylladb.com/product/benchmarks/aws-i3-metal-benchmark/ is
> garbage as their rational is completely flawed in choosing less bare metal
> nodes (but far bigger) - they have exponentially reduced the communication
> costs... Additionally, running single Java nodes on the metal machine would
> perform far better. Also, the GC tuning is not designed for latency with
> max pauses of 500ms.
>
> Re-run the tests on Shenandoah or Zing and see how they compare.
>
> -Original Message-
> From: Henrik Johansson
> Sent: Feb 12, 2020 9:10 AM
> To: Kevin Chadwick
> Cc: golang-nuts
> Subject: Re: [go-nuts] Go without garbage collector
>
> Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times
> better so that particular example isn't really helping the GC case.
>
> I don't mind the GC myself but I hear the "GC is actually faster" often
> and it seems not to be true in the wild although I am sure theoretical
> cases can be envisioned.
>
> On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:
>
>> On 2020-02-12 14:02, Robert Engels wrote:
>> > Most of that is because their codebase predates Java. There are more
>> modern dbs
>> > like Cassandra that are in Java. Certainly Hadoop is probably the
>> largest
>> > distributed database in the world and it’s written in Java.
>>
>> Bound to use more cpu cycles and memory than a c equivalent. Of course
>> postgres
>> is more capable.
>>
>>
>> https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/
>>
>> --
>> You received this message because you are subscribed to the Google 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/f388606c-7f52-78bc-f59c-776688114e4f%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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com?utm_medium=email_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/CAKOF694QKE4Ha9mRf7eRCq9PiB5WEtrCYBgcSrAmF-RmaXL0_g%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times
better so that particular example isn't really helping the GC case.

I don't mind the GC myself but I hear the "GC is actually faster" often and
it seems not to be true in the wild although I am sure theoretical cases
can be envisioned.

On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:

> On 2020-02-12 14:02, Robert Engels wrote:
> > Most of that is because their codebase predates Java. There are more
> modern dbs
> > like Cassandra that are in Java. Certainly Hadoop is probably the largest
> > distributed database in the world and it’s written in Java.
>
> Bound to use more cpu cycles and memory than a c equivalent. Of course
> postgres
> is more capable.
>
>
> https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/
>
> --
> You received this message because you are subscribed to the Google 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/f388606c-7f52-78bc-f59c-776688114e4f%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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

Sure, writing these system in a non-GC language is harder but that's not
really what is talked about here right?
There is a reason why databases are not really successful in Java for
example. Caching software are predominantly in C/C++.
Beating highly tuned C/C++ is not something that a GC can do by itself.
What it brings is convenience and frankly it's "good enough"
for most cases. We shouldn't pretend that GC is be all end all to both
developer and runtime performance.

On Wed, Feb 12, 2020 at 2:10 PM Robert Engels  wrote:

> Aren’t we all all “students” :)
>
> The conclusions you cite are from the 2005 paper.
>
> I’m sure I can find other more recent peer reviewed papers that draw the
> same conclusions as the “student” one.
>
> I don’t think it is necessary though. If you understand how malloc or
> tcmalloc and how modern GC works you’ll also know why it’s the case. Even
> with tcmalloc, highly concurrent dynamic memory systems are a problem
> without GC. A simple example, with Rust dealloc a large dynamic object
> graph vs a GC language- expensive vs cheap.
>
> On Feb 12, 2020, at 6:36 AM, Brian Candler  wrote:
>
> 
> On Wednesday, 12 February 2020 05:00:41 UTC, robert engels wrote:
>>
>> I found a more recent academic paper that proves my conclusions:
>>
>>
>> https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection
>>
>>
> It's a student paper.
>
> The bit that caught my eye was results of simulation using real Java
> programs:
>
> *it’s been proven that the runtime performance of the best-performing
> garbage collector is competitive with explicit memory management when given
> enough memory. In particular, when garbage collection has five times as much
> memory as required, its runtime performance matches or slightly exceeds
> that of explicit memory management.*
>
>
> *However, garbage collection’s performance degrades substantially when it
> must use smaller heaps. With three times as much memory, it runs 17% slower
> on average, and with twice as much memory, it runs 70% slower.*
>
> --
> You received this message because you are subscribed to the Google 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/230ed453-0897-48a7-8662-4807e7774e85%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/EF2B49E6-2A39-4582-9308-84F5D35F91EA%40ix.netcom.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/CAKOF697R-VmPxbjuP8%2BkFkO5J2M9JVKjK44qNX_Qb1AczZAHcA%40mail.gmail.com.

Re: [go-nuts] [ANN] GoLand 2020.1 EAP starts with Go Modules improvements and Go 1.14 support

[Henrik Johansson]

Outstanding IDE!
I was always impressed with JetBrains stuff but Goland really rocks!

On Fri, Feb 7, 2020 at 10:20 AM Florin Pățan  wrote:

> Hi Gophers,
>
> I'd like to announce the start of the 2020.1 Early Access Program of
> GoLand IDE, the JetBrains dedicated IDE for Go development.
> A few highlights from the release include:
>
>- support for Go 1.14
>- improved support for Go Modules
>- improved code completion, Live Templates, and Postfix templates
>- performance improvements
>
> You can find more information about our release on the dedicated blog page
> 
> .
>
> We'd like to hear your feedback on how to improve the product and deliver
> a stable and exceptional experience for Go developers.
>
> 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/b08aae9f-f0ed-4af1-a59d-c941e0d36213%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/CAKOF694Cn89xEGhN9dbDWJtV_7UVoD3sSy_Ty_x8J80GAhC%2BoQ%40mail.gmail.com.

Re: [go-nuts] Re: Contracts Draft: why are method pointers allowed

[Henrik Johansson]

Why make any distinction between pointers and non pointers? Isn't the
(usual) point to allow the caller to decide upon instantiation?
We define a contract in terms of an unknown set of types and then let
whoever uses it fullfil the contract however they want?

On Tue, Jul 30, 2019, 21:57  wrote:

>
> On Tuesday, July 30, 2019 at 7:47:05 PM UTC+1, Axel Wagner wrote:
>>
>> On Tue, Jul 30, 2019 at 8:31 PM  wrote:
>>
>>> My suggestion was that you can't use a pointer type as a type parameter
>>> if the latter is subject to a contract.
>>>
>>
>> I'm not sure I understand you. Wouldn't that preclude using a generic map
>> with pointers as keys?
>>
>
> No, it wouldn't preclude that but the key would need to expressed as a *K
> rather than a K, if K were subject to a contract. As a pointer type it
> would automatically follow that *K was comparable.
>
>>
>>
>>> In the case you mention, the contract could be expressed as a
>>> disjunction of value and pointer methods:
>>>
>>> contract stringer(T) {
>>>T String() string, *T String() string
>>> }
>>>
>>
>> Currently, Disjunctions only apply to a single type. You can't form
>> expressions like this.
>> IMO that's a good restriction to maintain. Because the more powerful the
>> contract language becomes, the harder it'll be to make it useful.
>>
>
> Well, currently you can't use *T as a method receiver type in a contract
> so this would be a necessary exception to that rule if my suggestion were
> adopted.
>
> However, I agree with your general point that the restriction should be
> maintained in all other circumstances.
>
>>
>>
>>> On the other hand and more generally, not knowing whether the type
>>> parameter represented a pointer or a value might lead to some awkward
>>> coding. For example, you wouldn't be able to de-reference the type argument
>>> as it might not be a pointer.
>>>
>>
>> If a generic function wants to de-reference an argument, it should
>> specify that as a pointer: func f(type T) (p *T)
>> This is the same as with slices, maps, channels, functions or any
>> composite type - you can't express "type parameter T should be a slice of
>> some kind", because you are instead expected to just specify []T if you
>> want a slice.
>>
>
> Yes, but if T happened to be a pointer to some type, then *T would be a
> double pointer to that type. As the design currently stands, you'd have no
> way of knowing whether T was a pointer or not unless the contract specified
> that it was one of the predefined types.
>
> What I was trying to suggest here is that it would be helpful in some
> circumstances to know whether T was or was not a pointer type which would
> be a by-product of my suggestion.
>
> Alan
>
>
> --
> You received this message because you are subscribed to the Google 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/cb9b37fc-19d4-4d25-bac8-72da1ade20a5%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/CAKOF695ayjMH7fE_OFd_gu414zxK6Co%3DWK0sNYwUvYr4SyD0hw%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Henrik Johansson]

Reports of violations are not violations.
I assume the standard coc procedure kicks in to determine if violations
occurred or not.

On Sat, Jul 20, 2019, 10:24 Jan Mercl <0xj...@gmail.com> wrote:

> On Fri, Jul 19, 2019 at 10:39 PM Cassandra Salisbury 
> wrote:
> >
> > I encourage everyone to take a look at the code of conduct. I have had
> multiple reports from this particular thread.
>
> I, for one, have no idea why. But I guess Kafka would be delighted by
> this mysteriosity.
>
> --
> You received this message because you are subscribed to the Google 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-XBFRVJjnt1OdKYOTLMh_-6pzCAZBaK5faaxXFD73eEdQ%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/CAKOF6966uwzjxiv%2B885PPbGC6sQBOcYuDZK%2BLBN0c1JZbMj8_Q%40mail.gmail.com.

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

[Henrik Johansson]

Not sure if anyone has already mentioned the possibility that "try" could
actually improve error handling
by simply removing much of the tediousness. Both reading and writing all
the error checks becomes a
nail in my eyes even if realize that it is very important. What if "try"
could take some of that annoyance
away and simply make me focus on handling the errors where appropriate and
pass on where convenient?

On Tue, Jul 9, 2019 at 1:57 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Jul 9, 2019 at 1:48 PM Nicolas Grilly 
> wrote:
>
> > The goal of the try proposal is not to "save a few keystrokes".  The
> goal is to reduce error handling verbosity when reading code.
>
> It's not verbosity. It's error handling. And because error handling is
> usually not the happy path, it's good when it stands out clearly. That
> improves readability as the important part catches attention easier.
>
> Hiding important code in one line instead, or with even using nested
> try constructs, makes the important path easier to overlook or to not
> be aware of it at all. For me personally, try buys zero advantages at
> the cost of several disadvantages.
>
> PS: Maybe we all somehow confuse readability with comprehensibility.
>
> --
> You received this message because you are subscribed to the Google 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-W50W92FEKhf4tbSR%3D6wFr3Cc5u1QVWu%2BXnwQWpUCaMQw%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/CAKOF697rVz9jAWXJ%3DWbhBjzhokrJrFbngW4fwwe6W08Pup-dgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Henrik Johansson]

I am not making this argument but you are continuously referring to
experienced developer's preferences (perhaps someone else more if so I am
sorry).

Don't get me wrong. Experience is good and weigh a lot especially combined
with education and wits. Perhaps we can both concede that there are such
developers in both camps.

On Mon, Jul 1, 2019, 19:21 Robert Engels  wrote:

>
> I don't think that has anything to do with what I said.
>
> I stated that experienced developers with minimal Go experience can
> probably offer deeper insights than new developers with only Go experience.
>
> The Go team is experienced developers (at least the ones I know), AND have
> deep Go experience (I am assuming - but maybe not on the Go application vs
> internal development side).
>
> If you are making the claim that the Go team "knows all", then why even
> have these conversations in the first place? Why have any community
> involvement at all? I am pretty sure this is not the position of the "Go
> team".
>
> -Original Message-
> From: Henrik Johansson
> Sent: Jul 1, 2019 12:14 PM
> To: robert engels
> Cc: David Suarez , golang-nuts
> Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?"
> anti-proposal
>
> This is funny since you are perfectly describing the Go core team... ;)
>
> I really can't get my head around it that this topic generates so much
> vitriol (maybe harsh).
> Generics I kinda get but this is just incredible.
> Don't like try? Don't use it.
>
> On Mon, Jul 1, 2019, 18:42 Robert Engels  wrote:
>
>> I think that is going to suffer greatly from sampling bias.
>>
>> You may have an engineer with 20+ years of programming in a variety of
>> languages - using both exceptions, and error values, and be new to Go, but
>> still have substantial insight as to the relative merits and drawbacks of
>> proposed options.
>>
>> In fact, I would argue that it is these experienced engineers that can
>> foretell the "end result" of various paths with far greater accuracy than a
>> new developer with multiple years of nothing but Go experience.
>>
>> Nothing is new, it is an impedance matching exercise.
>>
>>
>> -Original Message-
>> From: David Suarez
>> Sent: Jul 1, 2019 11:16 AM
>> To: golang-nuts
>> Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal
>>
>> The number of posts on this topic piqued my curiosity so I hope to add
>> some considerations after doing some research on this trail that I hope you
>> find useful.
>>
>> TL;DR:  It is possible that the reason for the interest in improving
>> "exception handling" in the proposed way is driven by individuals that are
>> not yet fully comfortable in the language
>>
>> From what I have gathered, the reason for improving this area was due to
>> a Go Survey.  This reminds me of this popular quote:
>> Quote. “*If* I had *asked* people what *they wanted*, *they* would have
>> said faster horses.”  Henry Ford, Innovation,
>>
>> Please note that while I did not participate in the survey, I would
>> probably have said the same thing until I got "used to it".  The
>> interesting support bit from the survey was the answer to, "I have used Go
>> for..."  -  suggests that 1/3rd of the respondents have only 1 year
>> experience or less with the language and a full half have less than 2 years
>> experience. In my experience, when I started Go I was (and still am in some
>> cases) using some Java paradigms in them that make sense to me which is
>> great for transition but may not be great for the language long run
>>
>> I am sure folks that have been around a while would agree that some of
>> the reasons they are considering or actively changing languages tend to be
>> due to bloat and unnecessary features that eventually weigh down
>> productivity because there are 10 ways to skin the cat and everyone has a
>> different opinion due to either how the rest of the code base does it or
>> what is new.
>>
>> The large response to this thread suggests that potentially there may be
>> a better feature out there that merits some attention and I would suggest
>> it may be something that should come from the 2+ years experience crowd (if
>> weighting of the results is possible) as those are likely the challenges
>> that newbies like me will eventually encounter.  Weighing the survey
>> results by experience may help Go stay ahead of the curve.  Just my .02
>>
>> **  Side note:  I am a relative newcomer to Go (~8-9 months

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

[Henrik Johansson]

This is funny since you are perfectly describing the Go core team... ;)

I really can't get my head around it that this topic generates so much
vitriol (maybe harsh).
Generics I kinda get but this is just incredible.
Don't like try? Don't use it.

On Mon, Jul 1, 2019, 18:42 Robert Engels  wrote:

> I think that is going to suffer greatly from sampling bias.
>
> You may have an engineer with 20+ years of programming in a variety of
> languages - using both exceptions, and error values, and be new to Go, but
> still have substantial insight as to the relative merits and drawbacks of
> proposed options.
>
> In fact, I would argue that it is these experienced engineers that can
> foretell the "end result" of various paths with far greater accuracy than a
> new developer with multiple years of nothing but Go experience.
>
> Nothing is new, it is an impedance matching exercise.
>
>
> -Original Message-
> From: David Suarez
> Sent: Jul 1, 2019 11:16 AM
> To: golang-nuts
> Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal
>
> The number of posts on this topic piqued my curiosity so I hope to add
> some considerations after doing some research on this trail that I hope you
> find useful.
>
> TL;DR:  It is possible that the reason for the interest in improving
> "exception handling" in the proposed way is driven by individuals that are
> not yet fully comfortable in the language
>
> From what I have gathered, the reason for improving this area was due to a
> Go Survey.  This reminds me of this popular quote:
> Quote. “*If* I had *asked* people what *they wanted*, *they* would have
> said faster horses.”  Henry Ford, Innovation,
>
> Please note that while I did not participate in the survey, I would
> probably have said the same thing until I got "used to it".  The
> interesting support bit from the survey was the answer to, "I have used Go
> for..."  -  suggests that 1/3rd of the respondents have only 1 year
> experience or less with the language and a full half have less than 2 years
> experience. In my experience, when I started Go I was (and still am in some
> cases) using some Java paradigms in them that make sense to me which is
> great for transition but may not be great for the language long run
>
> I am sure folks that have been around a while would agree that some of the
> reasons they are considering or actively changing languages tend to be due
> to bloat and unnecessary features that eventually weigh down productivity
> because there are 10 ways to skin the cat and everyone has a different
> opinion due to either how the rest of the code base does it or what is
> new.
>
> The large response to this thread suggests that potentially there may be a
> better feature out there that merits some attention and I would suggest it
> may be something that should come from the 2+ years experience crowd (if
> weighting of the results is possible) as those are likely the challenges
> that newbies like me will eventually encounter.  Weighing the survey
> results by experience may help Go stay ahead of the curve.  Just my .02
>
> **  Side note:  I am a relative newcomer to Go (~8-9 months) so there is
> likely some bias there from my newness.  Add salt here
>
> On Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:
>>
>> 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/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com
> 

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

[Henrik Johansson]

If it is as bad as "every sane Go shop" comes to this conclusion then I am
sure "try" will not be added...

On Mon, Jul 1, 2019 at 12:57 PM Wojciech S. Czarnecki 
wrote:

> On Mon, 1 Jul 2019 12:33:16 +0200
> Henrik Johansson  wrote:
>
> > That is one big strawman. I can live without "try" but
> > I think it would be a net gain for the language.
>
> I think it would be not. While anyone who consider 'try()' func being
> awkward
> and full of traps need not to use it in her code, everyone will have to
> cope
> with it while reading others code. Here lie dragons.
>
> 'Try()' might end as the first and topmost position on Go's "WE DON'T"
> blacklist. So it will waste Go team's time on implementing then
> maintaining,
> then every sane Go shop will forbid it.  (As it happened to C++ exceptions
> and many other C++ 'features' --  I'd seen 'we-dont' lists with over dozen
> positions).
>
> TC,
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> You received this message because you are subscribed to the Google 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/20190701125733.4c41b9b2%40zuzia
> .
> 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/CAKOF695i%3Dnu8W2ujL6RQ_VNEQjHAjP9HAHarz5p4UnQJzNJYyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Henrik Johansson]

That is one big strawman. I can live without "try" but I think it would be
a net gain for the language.
Sign of the times that any discussion becomes polarized I guess...

On Mon, Jul 1, 2019 at 12:18 PM Denis Cheremisov 
wrote:

> > I think many people like the proposal but are not vocal about it.
>
> Emoji count should reflect that "silent majority" better than comments. We
> have larger negative count on `try` and overwhelming 1293 vs 154 positive
> count on leaving it as is. People who care generally dislike poorly thought
> `try`, that's it.
>
> воскресенье, 30 июня 2019 г., 15:47:54 UTC+3 пользователь
> pierr...@gmail.com написал:
>>
>> Indeed.
>>
>> I think many people like the proposal but are not vocal about it. It is
>> not perfect but it *does *bring value to the table if you read the
>> proposal in its entirety and think about how you would use/could use it in
>> a real life scenario.
>>
>> I do *decorate *errors a lot, I do care about the *control flow* (I have
>> been along time user of *defer *for error handling and find it not
>> magical or ugly but fitting beautifully with the language), which are the
>> main topics people are complaining about... And I think it actually works
>> fine in those situations.
>>
>> In fact, the try() approach has started growing on me as I write code
>> now, I feel it would help in quite a few situations and simplify, not in a
>> drastic way, but subtle and valuable one.
>>
>> My 2c.
>>
>> Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :
>>
>>> I for one like the try proposal. It removes much of my gripes with the
>>> verbosity of error handling.
>>>
>>> I think that it will become more readable than explicit error handling
>>> quite fast. Note that it is still explicit, if you don't use the try
>>> notation the error can be handled as it is now or ignored as it sometimes
>>> is now.
>>>
>>> I have a feeling that there is a quite large "silent majority" that
>>> pretty much agrees with me.
>>>
>>> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov 
>>> 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 golan...@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/49411503-e6f1-4be7-ae39-57b55e782779%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/49411503-e6f1-4be7-ae39-57b55e782779%40googlegroups.com?utm_medium=email_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/CAKOF697dWwSHcNi%3DS4ErwLVpEtV%3Dem8UExnQZiLbnpwOUDrkNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Henrik Johansson]

I for one like the try proposal. It removes much of my gripes with the
verbosity of error handling.

I think that it will become more readable than explicit error handling
quite fast. Note that it is still explicit, if you don't use the try
notation the error can be handled as it is now or ignored as it sometimes
is now.

I have a feeling that there is a quite large "silent majority" that pretty
much agrees with me.

On Sat, Jun 29, 2019, 21:18 Denis Cheremisov 
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/CAKOF6978Z_hK2g_2GFDxCzqHQxi5Eeon0N2gOx3dUYbB-TbbYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How go-mysql-driver get data? "get all data at a time" or "only get a batch when we call rows.Next"?

[Henrik Johansson]

I am pretty sure it's the latter case with lazy loading when needed during
the Next() call.

On Wed, Jun 26, 2019 at 2:59 PM 杜沁园  wrote:

> When we operate with mysql with Go, as follow:
>
>
> rows, err := db.Query()
>
> for rows.Next() {
> .
> }
>
>
> When the driver get data?
>
> Get all data at once when we call `Query`???
>
> Or only get a batch of Data when we call `Next`, and get next batch of
> data when we run out of 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f55712f4-a29e-42b8-84cf-0b39b1d0b32f%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/CAKOF697ZCj80uV39izsjeJpx1oRg%2BGv_YXJO4avaktdjxPFK0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is there a goroutine scope global veriable ?

[Henrik Johansson]

On a practical note I think thread local storage is more or less
discouraged in for example Java as well
because it makes all the new shine "reactive" tools break since they make
no guarantees as to which thread you are running on.

That may or may not be relevant to your case but to say that it's standard
practice is probably not true any more.

On Wed, Jun 19, 2019 at 8:49 PM Michael Jones 
wrote:

> For the OP:
>
> A thought to share on the general topic: Go is pioneering a sufficiently
> different model of concurrent computation that it may not make much sense
> to ask for or seek equivalencies with classic thread/process models.
>
> This says nothing against the standard model, nor against the “missing”
> services; it is a note to encourage design in Go along with coding in Go,
> instead of design in C/C++/Java/POSIX/... and a best-effort realization in
> Go.
>
> By way of analogy, I’ve long been involved in boat design and
> construction. We always use a pair Furuno or Simrad RADAR antennas, one of
> long range and one short, to optimize object detection/clutter rejection
> and as a redundancy safety factor. However, when sailing on a HobeeCat,
> i’ve never looked for nor missed the Radar or any other instruments of
> navigation. A HobieCat is just such a different idea of sailing that *all*
> the normal mechanisms have no place.  There is no “where do I stow the
> anchor” or “where do I control the RAM signal lights.” There are whole
> chapters of the USCG instructions (ColRegs) where the thing discussed is
> not on a HobeeCat. That does not make such boats inadequate; it makes them
> fun.
>
> If you can stop thinking of concurrency in Go as a small group of
> exquisitely instrumented machines and instead imagine a swarm of ants,
> you’ll find new and interesting ways to solve problems. They often work
> even better, and are also more fun.
>
> On Wed, Jun 19, 2019 at 9:37 AM Robert Engels 
> wrote:
>
>> Side-managed thread/execution context has been around since the concept
>> of a thread. It is highly useful, and is more robust and secure than a
>> Context object passed among methods.
>>
>> If Go had any concept of a "secure runtime" it would be essential, but it
>> doesn't, so you make do with what you have.
>>
>>
>> -Original Message-
>> From: jake6...@gmail.com
>> Sent: Jun 19, 2019 11:08 AM
>> To: golang-nuts
>> Subject: [go-nuts] Re: is there a goroutine scope global veriable ?
>>
>> This has been discussed many times before. Searching "local storage" on
>> this group brings up many discussions, including:
>>
>> https://groups.google.com/d/topic/golang-nuts/Nt0hVV_nqHE/discussion
>> https://groups.google.com/d/topic/golang-nuts/_Vv7Bzn8yH4/discussion
>> https://groups.google.com/d/topic/golang-nuts/zuWWBHKn6iw/discussion
>>
>> My take is that GLS could be genuinely useful in a few cases, but would
>> undoubtedly lead to abuse in most cases. In the vast majority of
>> situations, what you really want to track, or log, is the specific work
>> being done, not actually which goroutine it happens to be running on. For
>> example, tracking a specific request, etc. My advice is to pass around a
>> context, or some other identifying information about the specific work
>> being done. At first this will seem tedious and annoying, but you will
>> likely get used to it.
>>
>>
>> On Tuesday, June 18, 2019 at 10:59:09 PM UTC-4, hui zhang wrote:
>>>
>>> is there a goroutine scope global veriable ?
>>> like  fork a variable from main ?
>>>
>> --
>> You received this message because you are subscribed to the Google 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/53512dd1-8c24-460d-9bf5-646ea1e95d0f%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/1187971360.3926.1560962237733%40wamui-berry.atl.sa.earthlink.net
>> 
>> .
>> 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 

Re: [go-nuts] [Job] remote Go developer at Mattel (fulltime, US-only)

[Henrik Johansson]

Wow! I live outside the US but this really makes me want to work for
Mattel. Sounds like a great place to work.

On Tue, Jun 18, 2019, 22:07 Nate Finch  wrote:

> Want to work with me at Mattel on a Go platform?
>
> Mattel’s Connected Products Platform team is *the model* of where Mattel
> is going with its products. It is a service platform expanding to be used
> by teams all across the whole 30,000 person company.
>
> We’re looking for a senior backend developer who is very comfortable with
> writing Go.
> Preferably you have experience working on backend game servers and/or
> delivering backend API services in production used by large numbers of end
> users.
>
> The recently launched Hotwheels id
>  track
> and app leverage our Platform for login, stat storage, firmware upgrades
> and more.
>
> Brands all across Mattel are making products shipping soon that leverage
> the services that our team is building – identity and login services, data
> and download APIs, all written in Go, running on Kubernetes in Google Cloud.
>
> We store data in postgres and redis, leverage Google’s pubsub service, and
> are looking more into serverless to scale our loads.
>
> We monitor with prometheus, grafana, pagerduty and sentry.  We talk on
> Teams, all changes get reviewed on github and tests must pass in CI on
> Jenkins
>
> Want great benefits? How about great pay, half day Fridays in the summer,
> unlimited vacation, very low deductible health insurance, high match 401k,
> and more.
>
> We are very conscious of work-life balance, and many people on the team
> have kids and work around busy life schedules.
>
> You’ll join a fully remote dev team and mostly remote wider team that has
> a big impact on a huge company. While Mattel is big, our division is small
> and given a lot of leeway in how we run things.
>
> Here’s the place to apply, please ignore basically everything on that page
> except the apply button. I have Opinions™ about its contents, and since I’m
> the hiring manager, what I say goes :)
>
> Yes it really is (US) remote, even though it says otherwise.
>
>
> https://jobs.mattel.com/job/el-segundo/platform-software-engineer-game-service/2015/12083533
>
> Please feel free to message me any questions before or after.
>
> If you don’t hear from someone within two business days of applying
> *PLEASE MESSAGE ME*.  <-- that’s in caps so you know you won’t be
> “bothering” me. Getting someone hired is super important, but sometimes
> balls get dropped.
>
> If you are underrepresented in tech, please consider applying. If you
> aren’t looking, please share this. Mattel values diversity, and so do I.
> Everyone loves toys, everyone can be a parent. We need a variety of
> viewpoints to ensure our products are great for everyone.
>
> If you want to talk before applying, feel free to DM me. If you’d rather
> talk to someone other than some cis white dude, ping @Claudia4Justice on
> Twitter.
>
> If you identity as a woman, non-binary, gay, bi, ace, queer, black, brown,
> differently abled, or otherwise, please apply. We need your particular
> insight. Diversity makes better products and teams. If you need special
> considerations, we will fight to get them for them for 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/84974a28-66bf-4e6a-b341-c646cc7dee3c%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/CAKOF6974yoAqdSTYLjKfH2S8sZ_zUuqBTpp3jnJEtjjep5NVXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How can I compile my project only relay on my vendor folder with go modules?

[Henrik Johansson]

I think "go mod vendor"
 does the trick as stated in "go mod help vendor".

On Tue, Jun 11, 2019 at 11:12 AM 唐彦昭  wrote:

> I need put my project on the server to compile.But my server can't connect
> to internet.
> So I need to put all my relay in my vendor folder in my develop
> environment.
> How can I do this with go 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e7f1ae76-3d41-494b-b771-0efc1a3c5784%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/CAKOF697O1_6cG6W%2ByG3wYY%3Dm31xymBMxD-poDLYcZwN%3DsPr4Wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] New development tool: missing watch mode for "go"

[Henrik Johansson]

I have always used https://github.com/cespare/reflex what is the main
benefit vs this and the other quite numerous options?

tis 23 okt. 2018 kl 11:28 skrev Nelo Mitranim :

> Good day gophers!
>
> I want to highlight a certain Go development tool. My golleagues (sic) and
> I have found it quite enjoyable to use: https://github.com/Mitranim/gow
>
> "gow" is the missing watch mode for the "go" command. It's invoked exactly
> like "go", but watches files and reruns the subcommand on changes.
>
> Common use cases:
>
>   gow run .
>
>   gow test
>
>   gow vet
>
> Clear terminal on restart with "-c":
>
>   gow -c run .
>
> Another fancy feature: hit "^R" to restart the subprocess. See "-h" for
> more options.
>
> I hope others will find this equally enjoyable. Feedback and requests for
> improvement are welcome.
>
> --
> You received this message because you are subscribed to the Google 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] Sharing data via Mutex vs. Channel

[Henrik Johansson]

Mutexes aren't expensive when compared to channels. They are usually harder
to get right and that's why there is the old Go mantra:
"Don't communicate by sharing memory; instead, share memory by
communicating."

I would say you should use what fits the use case but prefer channels if
possible.


tis 23 okt. 2018 kl 12:19 skrev 'Reinhard Luediger' via golang-nuts <
golang-nuts@googlegroups.com>:

> Hi folks,
>
> somwhere on my golang journey ("don't k now where and when") I was teached
> that mutexes are very expensive and we should prefer to communicate over
> channels instead of working with mutexes.
> I trusted it until today. I explained it to our aprentice based on my
> knowledge and he asked me  if i can show him the performance difference.
>
> Therefore I wrote this little demo with the expectation that the channel
> solution will beat the mutex one and was really surprised when I saw that
> the mutex based solution beats the channels one most of the time by factor
> 2.
>
> https://play.golang.org/p/Kf9VBSoTLcU
>
> What am I missing here or is it not true anymore that mutexes are so
> expensive that we should prefer Communicating over Sharing.
>
>
> kind regards
>
>
> Reinhard Lüdiger
>
> --
> You received this message because you are subscribed to the Google 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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Henrik Johansson]

I know what a uintptr is but what would you put in it if not a pointer to
another object?
Isn't this very analogous to what you said: "a weak hashmap uses weak
references to refer to the contained objects so that they will be collected
if nothing else refers to them".

Maybe I am missing something. I never meant to imply that they worked the
same way _internally_ but at a conceptual level.

fre 28 sep. 2018 kl 15:12 skrev Robert Engels :

> His statement is correct. First of all, a weak reference in java is not
> like a weak pointer in C++, at least they are not needed to break cycles,
> as the GC is immune to that issue. The difference is that a weak hashmap
> uses weak references to refer to the contained objects so that they will be
> collected if nothing else refers to them, similar to a Lru cache. In this
> case it is a uintptr which is not a reference to anything, it is just an
> integer.
>
> On Sep 28, 2018, at 8:00 AM, Henrik Johansson 
> wrote:
>
> That's clever but irrelevant for this discussion.
>
> fre 28 sep. 2018 kl 14:57 skrev Jan Mercl <0xj...@gmail.com>:
>
>> On Fri, Sep 28, 2018 at 2:53 PM Henrik Johansson 
>> wrote:
>>
>> > The data pointed to by the uintptrs ...
>>
>> Uintptrs are integers. They do not point to anything.
>> --
>>
>> -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.

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Henrik Johansson]

That's clever but irrelevant for this discussion.

fre 28 sep. 2018 kl 14:57 skrev Jan Mercl <0xj...@gmail.com>:

> On Fri, Sep 28, 2018 at 2:53 PM Henrik Johansson 
> wrote:
>
> > The data pointed to by the uintptrs ...
>
> Uintptrs are integers. They do not point to anything.
> --
>
> -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.

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

[Henrik Johansson]

How is storing unintptrs in a map different from say java.util.WeakHashMap?
The data pointed to by the uintptrs can at any given time have been
reclaimed by the GC much the same as weak references in Java.

I am not saying you are using it the same way as one would normally use
weak references in other languages.

fre 28 sep. 2018 kl 14:17 skrev Peter Mogensen :

>
>
> On 09/28/2018 02:04 PM, Robert Engels wrote:
> > This is in no way similar to weak references in Java. Weak references
> > are safe and appropriate for many caching data structures. The code idea
> > presented here is not related.
>
> Correct.
> I've used weak references in other languages (not Java) to, say, prevent
> leaks due to reference cycles.
>
> This is not that.
> My idea could maybe be restated simpler as having a huge double-linked
> list of sync.Pool objects and using wanting to supplement it by a map
> index, but avoiding storing pointers in the map.
>
> I don't think I've seen any argument that it's technically impossible by
> now, but maybe there's better ways to do it ... maybe even write the
> index manually instead of using the build in map.
>
> I think the warning about this being "catastrophically unsafe" forgets
> that these objects will be kept with proper pointers in a separate data
> structure and the map was only intended as an index.
> It was never the intention to let an uintptr be the only remaining
> reference to the objects. There will of course, always be a need for
> keeping proper pointers in a datastructure (like a list) to be able to
> do proper Put() on the objects before the map reference is lost.
>
> Anyway... I think I've found a more efficient way using integer slice
> indexes instead of uintptr.
>
> Thanks for input
>
> /Peter
>
> --
> You received this message because you are subscribed to the Google 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] Huge map[string]*Object and GC where *Object is from sync.Pool

[Henrik Johansson]

This sounds much like the trickery people have used both successfully but
also disastrously using weak references in Java.
Is that where you got the idea from?


fre 28 sep. 2018 kl 08:36 skrev Keith Randall :

> On Thu, Sep 27, 2018 at 11:26 PM Peter Mogensen  wrote:
>
>>
>>
>> On 09/28/2018 08:17 AM, Peter Mogensen wrote:
>> >
>> >
>> > On 09/28/2018 03:04 AM, keith.rand...@gmail.com wrote:
>> >> Objects returned by Get() are not special in any way. They will be GCd
>> >> just like an object returned by new(). In fact, they will often be just
>> >> a new()'d object.
>> >> There is no association of such an object with the pool.  A pool is
>> just
>> >> a fancy free list. Get might return a previously Put'd object instead
>> of
>> >> a new() one.
>> >>
>> >> Your scheme is unsafe. Storing a *Object as a uintptr means the
>> >> underlying Object will be collected out from under your map.
>> >
>> > Ok... thanks... I guess I might have made the wrong assumption about
>> > when objects returned from pool.Get() are subject to garbage collection.
>> >
>>
>>
>> However... (it's early here, so I forgot).
>>
>> Of course the uintptr entries in the map is not the only reference to
>> the objects. In order to properly clean up there will be another
>> datastructure holding (say) a linked list of the objects.
>>
>> For instance... if the map is only used as index to a huge database,
>> where the objects are actually stored in a priority queue to, say,
>> implement TTL or LRU.
>>
>> So, there would always be another reference to the objects preventing
>> them for being garbage collected.
>>
>>
> It's not guaranteed to work according to the spec. The thing that will
> break your code is moving objects.
> The GC currently doesn't move objects in the heap.
> We do copy stacks, but the current escape analysis never puts objects
> pointed to by a map entry on the stack.
> So for now, you're ok. If we ever implement a moving garbage collector or
> improve escape analysis, you're out of luck.
>
>
>> /Peter
>
>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/NPdHLvOoCp8/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: Perf : Multithreaded goroutines files I/O

[Henrik Johansson]

Perhaps you can try https://github.com/avikivity/diskplorer to estimate how
many readers you should optimally create.

mån 17 sep. 2018 kl 11:33 skrev Thomas S :

> Is my time display method wrong ?
>
> t := time.Now()
> // Process
> fmt.Println(time.Since(t))
>
>
>
> Le dimanche 16 septembre 2018 22:54:33 UTC+2, Michael Jones a écrit :
>
>> don't be confused about internal process time and external wall clock
>> time here.
>>
>> On Sun, Sep 16, 2018 at 11:27 AM Thomas Solignac 
>> wrote:
>>
> I think the concurrent read overhead compensates the process
>>> parallelization !
>>>
>>> Both files are in attachment.
>>>
>>> Thank you for helping :-)
>>>
>>>
>>>
>>> Le dimanche 16 septembre 2018 20:02:33 UTC+2, Marc Zahn a écrit :

 You mean, loading the files in parallel take the ~same time as loading
 them sequentially? It seems that there is somewhere else a bottleneck...

 Am Sonntag, 16. September 2018 14:08:50 UTC+2 schrieb Thomas Solignac:
>
> Hello,
>
> I have a loading step, where I have something like 60 files to read
> and process, as fast as possible.
> I tried loading with goroutines and without, and I get substantially
> the same process time (38s).
>
> *What is the more idiomatic ? Is Golang designed for concurrent files
> I/O ?*
>
> Note : One file per goroutine (not multiple concurents I/O on the same
> file)
>
> Thanks for reading :-)
>
 --
>>> You received this message because you are subscribed 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.
>>>
>>
>> --
>>
>> *Michael T. jonesmichae...@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] Go memory usage inside containers

[Henrik Johansson]

taskset works for sure and I managed to crash a program with ulimit.
I thought these stuff was what the container runtimes used under the hood.
Am I missing something?

ons 12 sep. 2018 kl 16:14 skrev Ian Lance Taylor :

> On Wed, Sep 12, 2018 at 7:07 AM, robert engels 
> wrote:
> > With the Azul VM (and I believe the G1 collector in Java), the VM is
> definitely aware of memory pressure as it approaches the maximum limit -
> then it will increase the concurrent GC activity trying to avoid a
> potential huge pause if the limit was reached - so throughput is lowered.
> >
> > I would think the Go GC needs to do this as well in order to limit pause
> times.
>
> That does not sound precisely correct to me.  The Go GC pause time is
> independent of the heap size, and I would expect that Java's pause
> time is as well.  It's certainly true that Go could run the GC harder
> when coming closer to a memory limit, which will tend to starve the
> program, but it won't actually pause the program.  As I mentioned
> earlier, though, when the program is coming close to its memory
> limits, it needs to react.  If it's a network server, it needs to stop
> accepting new connections.  If it has cached data, it needs to discard
> it.  And so forth.  The GC can try harder but if the program keeps
> allocating more memory there is nothing the GC can do to save it.
>
> 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.
> 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 memory usage inside containers

[Henrik Johansson]

Afaik it works fine for Go programs  as long as these limits translates to
things like taskset etc.

ons 12 sep. 2018 kl 08:48 skrev Leigh McCulloch :

> Hi,
>
> Does anyone here know how Go interacts with memory limits inside
> containers? (e.g. Kubernetes, Docker)
>
> Does the Go runtime have similar problems as the Java runtime, in that it
> doesn't know what the container limit is, and only knows what the physical
> limit is for the entire instance?
>
> Or is Go aware of limits placed on the container?
>
> (I've witnessed the Go runtime package say the NumCPU is the total
> physical count when the app has been limited to many less CPUs, so it seems
> like it doesn't have visibility into the CPU limitations.)
>
> Thanks,
> Leigh
>
> --
> You received this message because you are subscribed to the Google 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 maven plug-in 2.2.0 has been published in maven central

[Henrik Johansson]

I have lived through all versions of Maven in large scale and the switch to
the Go way has brought me nothing but joy and peace.
Maven works, I agree, but thats it. it's not joyful and simple in the same
way as Go's way of building that mostly (modulo versions) gets out of your
way.

I am impressed that you took the time to implement this however and if it
can generate more Go developers all the better!


tis 15 maj 2018 kl 09:33 skrev Igor Maznitsa <rrg4...@gmail.com>:

> *short note for developers who knows nothing about maven*
>
> 1. maven <https://maven.apache.org/> is a well-documented cross-platform
> mature tool with long history
> 2. maven <https://maven.apache.org/> is open-source and small one
> 3. maven <https://maven.apache.org/> is accessible in popular OS software
> repositories
> 4. maven <https://maven.apache.org/> is widely used in enterprise world
> especially, the most popular it is in Java world but the tool allows to
> build native application too
> 5. maven <https://maven.apache.org/> is supported out of the box by
> popular CI (continuous integration) systems (like Jenkins)
> 6. maven <https://maven.apache.org/> has central repository which allows
> to distribute extensions without pain
> 7. its project configuration files should be written in XML what sometime
> is verbose but less possibility to make errors
> 8. it allows to tune project build process depending on current OS, it is
> possible to make specific profiles for each OS family
> 9. it has big active community
>
> *how it can help in Golang world*
>
> 1. it allows to not invent bicycle
> 2. Golang projects can use existing polished environment which allows
> build even enterprise level solutions
> 3. less time to involve Java programmers into Golang world
> 4. provided way to use synergistic effect from multi-language environment,
> for instance popular ANTLR <http://www.antlr.org/> tool (to generate
> parsers) provides only Java based solution but can generate Golang code.
>
> *what about me and why I have written the plug-in*
>
> 1. I don't like to dance around project environment tuning, I am too lazy
> 2. I don't like to have pain with 3th side dependency loading and control
> their version and changes
> 3. I very like to build everything through single command and move
> projects between machines without pain
> 4. I want distribute my projects without big notes how to build them and
> how to tune environment
>
>
> On Tuesday, May 15, 2018 at 9:31:08 AM UTC+3, Henrik Johansson wrote:
>
>> How in the name of anything does using Maven make life easier?
>> Hyperbole aside I am curious. How does it help?
>>
>> --
> You received this message because you are subscribed to the Google 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 maven plug-in 2.2.0 has been published in maven central

[Henrik Johansson]

How in the name of anything does using Maven make life easier?
Hyperbole aside I am curious. How does it help?

tis 15 maj 2018 kl 07:55 skrev Igor Maznitsa :

> as usual - to make life easier
>
>
> On Tuesday, May 15, 2018 at 8:36:40 AM UTC+3, kortschak wrote:
>>
>> Why!
>>
>> --
> You received this message because you are subscribed to the Google 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] gocql date field conversion issue

[Henrik Johansson]

There is a PR for `date` marshalling https://github.com/gocql/gocql/pull/878
that is merged March last year.
If you have gocql older than that I suggest trying to update but I am not
sure if it helps.

Timestamp/time.Time has always worked very well for me though so if you can
switch that could be an option.



ons 11 apr. 2018 kl 09:17 skrev Raju :

> I have a table in cassandra which looks like this:
>
> create table dailyusage(
>   name string
>   service string
>   date  date
> );
>
>
> I need to write a query in Go using gocql package to filter the results
> from dailyusage table based on a user provided date range
>
> I have created my query like this
>
> startDate := "2018-04-01"
> endDate  := "2018-04-03"
>
> var name, service string
> var date time.Time
>
> qstr := `SELECT name, service, date, FROM dailyusage WHERE date >= ? and date 
> <= ?`
>
> iter := ss.Query(qstr, startDate, endDate).Iter()
>
>
> for iter.Scan(, , ) {
>
>   // add to my list
>
> }
>
>
> if err := iter.Close(); err != nil {
>
>   fmt.Printf("Error closing iterator:%v \n", err)
>
> }
>
>
> When I run this, I am getting error -
>
> Error closing iterator. Error:can not marshal string into date
>
>
>
> If I change startDate and endDate to time.Time format, I am getting this
> below error
>
> Error closing iterator. Error:can not marshal time.Time into date
>
> Is there any way to address this conversion from string/Time in golang to 
> date format in cql/gocql?
>
>
> Thanks
>
> Raju
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google 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] [ANN] Elastic APM Go Agent

[Henrik Johansson]

Out of curiosity is it Open Tracing compatible?

On Wed, Mar 21, 2018, 02:55 Andrew Wilkins  wrote:

> Hi folks,
>
> Elastic APM [0] is an open source APM solution being developed by Elastic.
> The Elastic APM server [1] is written in Go. We've recently started working
> on a package for tracing/monitoring Go applications:
> https://github.com/elastic/apm-agent-go.
>
> Although the Go support is fully functional, it's still very early in
> development -- we're calling it "pre-alpha" to make it clear that the API
> is still very likely to change. Currently there's support for tracing (but
> not *distributed* tracing -- we're working on that), and we've started
> looking at adding support for application metrics.
>
> We'd be happy to hear your feedback on the Go agent, and what things you'd
> like to monitor in your Go applications. If you're interested and have 5-10
> minutes, please fill it out: https://goo.gl/forms/6CMMsqd6TVAYEEg42.
>
> Finally, if you want to follow along, I encourage you to either star/watch
> the repositories, and/or sign up to https://discuss.elastic.co/c/apm. I
> won't be posting this sort of thing regularly to golang-nuts, as I'm sure
> it's not of general interest.
>
> Cheers,
> Andrew
>
> P.S. It's called an "agent" for consistency, but really it's just a
> package you import into your application. That could change.
>
> [0] https://www.elastic.co/solutions/apm
> [1] https://github.com/elastic/apm-server
>
> --
> You received this message because you are subscribed to the Google 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: Would this race condition be considered a bug?

[Henrik Johansson]

That post is fantastic and horrible at the same time. It is mandatory read
for anyone endeavoring into concurrent programming however.

On Sun, Mar 18, 2018, 09:42 David Anderson  wrote:

> There's a difference though. The program that uses sync/atomic will behave
> non-deterministically, but within a small set of possible outcomes. The one
> without could do anything. In addition to producing an incorrect numeric
> result, it could deadlock, segfault, jump execution to some random place in
> the program code, ...
>
> I highly recommend
> https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
> . It's an excellent article (by the author of the go race detector) that
> explains why safe, benign data races are never safe or benign. The examples
> are in C++, but the same applies to Go - the compiler makes assumptions
> about code execution in the absence of synchronization points, and even
> simple optimizations can have hilarious consequences on code that violates
> those assumptions.
>
> - Dave
>
> On Sun, Mar 18, 2018 at 1:19 AM, Devon H. O'Dell 
> wrote:
>
>> Perhaps better illustrated:
>>
>> package main
>>
>> import (
>> "fmt"
>> "time"
>> )
>>
>> type info struct {
>> count int
>> idint
>> }
>>
>> var stop int32
>>
>> func runner(id int, c chan info) {
>> info := info{id: id}
>> for stop == 0 {
>> info.count++
>> time.Sleep(1 * time.Microsecond)
>> }
>> c <- info
>> }
>>
>> func main() {
>> c := make(chan info)
>> for i := 0; i < 10; i++ {
>> go runner(i, c)
>> }
>>
>> time.Sleep(10 * time.Millisecond)
>> stop = 1
>>
>> for i := 0; i < 10; i++ {
>> fmt.Printf("Returned %+v\n", <-c)
>> }
>> }
>>
>> This program is guaranteed to halt, regardless of any GOMAXPROCS
>> setting. If you use the race detector on this program, it will
>> complain. You can "fix" "the race" by changing the loop condition to
>> "atomic.LoadInt32() == 0" and use atomic.StoreInt32(, 1) as
>> your signal. Is the program still racy? Yep. Is either version of this
>> program buggy? That just depends. It's not too hard to think of cases
>> where this behavior might be desirable; even lossy counters are a
>> thing.
>>
>> --dho
>>
>> 2018-03-18 0:43 GMT-07:00 Devon H. O'Dell :
>> > 2018-03-16 2:16 GMT-07:00 Jérôme Champion :
>> >> Any race is a bug. When there is a race, the compiler is free to do
>> whatever
>> >> it wants.
>> >
>> > This is a false statement; whether or not a race constitutes a bug
>> > depends on the encapsulating protocol. Consider the following:
>> >
>> > package main
>> >
>> > import (
>> > "fmt"
>> > "sync"
>> > "sync/atomic"
>> > )
>> >
>> > var wg sync.WaitGroup
>> >
>> > type Spinlock struct {
>> > state uint32
>> > }
>> >
>> > func (s *Spinlock) Lock() {
>> > for atomic.SwapUint32(, 1) == 1 {
>> > }
>> > }
>> >
>> > func (s *Spinlock) Unlock() {
>> > atomic.StoreUint32(, 0)
>> > }
>> >
>> > func locker(s *Spinlock, i int) {
>> > defer wg.Done()
>> > s.Lock()
>> > fmt.Printf("Locker %d acquired lock\n", i)
>> > s.Unlock()
>> > }
>> >
>> > func main() {
>> > s := {}
>> > for i := 0; i < 10; i++ {
>> > wg.Add(1)
>> > go locker(s, i)
>> > }
>> > wg.Wait()
>> > }
>> >
>> > This program does not have deterministic output because each goroutine
>> > races to acquire the lock, and which gets it first relies on
>> > scheduling, which is effectively stoachastic. (Playground caches
>> > output, so no use illustrating it there.) Despite this, the program
>> > compiles just fine and behaves correctly for any reasonable definition
>> > of correct.
>> >
>> > I recognize this is not the issue mentioned in OP, but hopefully it's
>> > clear that this is not just a semantics argument (race doesn't just
>> > mean "only things the race detector can find") and that the statement
>> > "any race is a bug" is false. This race only constitutes a bug when
>> > the requirements of this program require deterministic output.
>> >
>> > --dho
>> >
>> >> What do you want to do? Do you want to println before or after
>> >> cancelContext? In your example, println could even be executed during
>> >> cancelContext!
>> >> Your example is not enough, such program :
>> >> https://play.golang.org/p/KJsYwu-ivjb would fix your problem, but I
>> don't
>> >> think that's what you asked for :)
>> >>
>> >>
>> >> Le vendredi 16 mars 2018 03:11:49 UTC+1, Anmol Sethi a écrit :
>> >>>
>> >>> https://play.golang.org/p/82Um1jSntBo
>> >>>
>> >>> Please run with the race detector to see the race.
>> >>>
>> >>> This race condition arises because private variables are read via
>> >>> reflection by the fmt 

Re: [go-nuts] Is channel push atomic?

[Henrik Johansson]

What do you mean atomic? The individual operations create happens before
edges afaik and since your channel is local there is nothing to worry about.
If you publish that channel then no I would say someone else can puh or
pull in between the two operations.

fre 9 mars 2018 kl 07:47 skrev Andrey Tcherepanov <
xnow4fippy...@sneakemail.com>:

> Hello fellow nuts,
>
> Is pull-push to a (same) channel atomic?
>
> func f() {
>ch := make(chan interface{}, 100)
>
>// ...
>
>ch <- <-ch // Is this an atomic operation?
> }
>
>
> Thank you very 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+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] Alibaba Cloud hash released official Go SDK v1.0.0

[Henrik Johansson]

I am sure it's really cool but the docs are in chinese I assume. Most other
projects speared by non native English speakers still write in English.

Is a translation available?

On Fri, Mar 2, 2018, 14:44  wrote:

> https://github.com/aliyun/alibaba-cloud-sdk-go
>
> Any questions you have when using it can be asked directly in the issue
> area
>
> --
> You received this message because you are subscribed to the Google 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 += Package Versioning

[Henrik Johansson]

A sidenote is that there seems to always be issues with using kubernetes
client.
Is it structured very un Go-ish?

Very nice writeup!

NB: I was also hit by the casing issue with the same viper dependency.

fre 23 feb. 2018 kl 08:28 skrev David Anderson :

> I should add: even though I spent several hours working through these
> issues, I feel very happy about the process and outcome. I have high
> confidence that I understand what vgo is doing with my module spec, and
> that I know how to tweak its thinking in future. I would contrast this with
> my experience with Glide. Last weekend, I tried to `glide up` this same
> project, and spent 4 hours trying to resolve the resulting mayhem of
> diamond dependencies and build errors. I failed, rolled back the change,
> and decided MetalLB could stay on old code for a while longer. I still have
> very low confidence that I understand what glide will do when I `glide up`,
> or that it will produce a working result.
>
> Additionally, some of the time spent is likely the learning curve. As
> https://github.com/golang/go/issues/24032 illustrates, I was initially
> confused and had to re-read some of rsc's writing to formulate my plan of
> action. Despite that, I still spent less time end to end than with glide,
> and I had a working build at the end of it.
>
> - Dave
>
> On Thu, Feb 22, 2018 at 11:20 PM, David Anderson  wrote:
>
>> This is an experience report onboarding vgo for a relatively complex
>> project (multiple binaries, vast import tree, tricky unidiomatic imports).
>> I leave it here in the hopes that it guides other people, and potentially
>> illustrates places where vgo falls short of great. TL;DR it went pretty
>> well, modulo a couple of UX speed bumps.
>>
>> The result is the `vgo-test` branch of https://github.com/google/metallb/
>> . Cloning that repository should allow you to `vgo test ./...`, `vgo build
>> ./controller`, `vgo build ./speaker`, and a few others. I don't make any
>> representation that the code does what it should, merely that it builds and
>> passes tests.
>>
>> The resultant go.mod,
>> https://github.com/google/metallb/blob/vgo-test/go.mod , is quite messy.
>> This is mostly due to the number of dependencies that have no semver at
>> all, forcing vgo to use commit hash "versions". The result is a lot of
>> visual noise in the file, but hopefully that will improve over time as both
>> vgo and dep nudge people towards semver releases.
>>
>> I encountered two major roadblocks on the road to `vgo test ./...`: the
>> Kubernetes client library, and mixed case packages. These are
>> https://github.com/golang/go/issues/24032 and
>> https://github.com/spf13/jWalterWeatherman/issues/22 respectively.
>>
>>
>> The Kubernetes client library is a worst case scenario for vgo. It
>> releases a new major version every 3 months under the same module name,
>> with real incompatibilities between versions; and it relies extensively on
>> a transitive version lock to force a specific package selection on its
>> dependents. Making this library usable from vgo required the following:
>>
>>- Fix up client-go in a fork
>>   - Fork github.com/kubernetes/client-go to
>>   github.com/danderson/client-go
>>   - Add a go.mod to the fork, containing only: module "
>>   k8s.io/client-go/v6"
>>   - Update all internal self-references within client-go: perl -pi
>>   -e 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
>>   - Commit the result,
>>   
>> https://github.com/danderson/client-go/commit/7d8481153a9edbf8eacc176ce29f8d58949c3a77
>>   . Tag as v0.0.0-vgo-prototype-compat and push.
>>- Make my repository use my fork of client-go:
>>   - Update all uses of client-go to the new versioned package name: perl
>>   -pi -e 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
>>   - Require the right version in mod.go: require "k8s.io/client-go/v6"
>>   v6.0.0
>>   - Replace upstream with my fork in mod.go: replace "
>>   k8s.io/client-go/v6" v6.0.0 => "github.com/danderson/client-go"
>>   v0.0.0-vgo-prototype-compat
>>
>> I'm curious how we could upstream the changes I had to make to client-go.
>> I had to rename module-internal imports, which will break existing non-vgo
>> uses of the library, but vgo offers no alternative to this renaming that
>> I'm aware of. It looks to me like there's no graceful upgrade path for this
>> module. The repo structure works either for pre-vgo clients, or for vgo,
>> but not both at once.
>>
>> The UX was lacking to explain the reason for failures, before I made any
>> of the changes. Given just my repository, vgo inferred that I wanted v1.5.2
>> of client-go (3+ years old), continued resolving dependencies, and
>> eventually barfed when it found an import for a client-go subpackage that
>> didn't exist in 1.5.2. The error was simply a bunch of "no such file or
>> directory", and required some head-scratching to 

Re: [go-nuts] Go += Package Versioning

[Henrik Johansson]

Why would that be a mistake? Working with tags and branches is what the VCS
is for. Extracting a given version and using that per the convention that
the import ends with the major version sounds very reasonable.

On Wed, Feb 21, 2018, 22:51 Zellyn  wrote:

> On Wednesday, February 21, 2018 at 4:45:25 PM UTC-5, Bakul Shah wrote:
>>
>> Something like
>> import "foo" v2
>> would be mildly preferable to me as
>> import "foo/v2"
>> can also refer to version 1 of a package named v2 (as opposed
>> to version 2 of foo) and the current naming rules continue to
>> work.
>>
>
> As I understood it, the fundamental philosophical point of today's rsc
> article was that you shouldn't use the the same "name" (identifier) for two
> different "things". If you look at it from that point of view, the "v2"
> should absolutely be part of the package URL. In fact, having the concept
> of version stored in some lookaside metadata outside of the name (eg. git
> tag) would be a mistake.
>
> Zellyn
>
> --
> You received this message because you are subscribed to the Google 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 += Package Versioning

[Henrik Johansson]

That's not necessarily true.
The tool can understand from the tag and assert or even rewrite the imports
to make the compiler happy.

On Wed, Feb 21, 2018, 21:51 Sam Whited <s...@samwhited.com> wrote:

> On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote:
> > But wait. Wasn't there a mention of archive downloads instead of relying
> on
> > the different VCS's?
> >
> > In the GitHub case I guess it amount to downloading releases (or any
> commit
> > I guess) as a zip or tarball.
>
> My understanding was that the path is still relavant, so you'd need a /v2
> directory inside the zip file, which means you probably need it in your
> source code. However, if that is incorrect it fixes the problem.
>
> —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.

Re: [go-nuts] Go += Package Versioning

[Henrik Johansson]

But wait. Wasn't there a mention of archive downloads instead of relying on
the different VCS's?

In the GitHub case I guess it amount to downloading releases (or any commit
I guess) as a zip or tarball.

On Wed, Feb 21, 2018, 20:54 Sam Whited  wrote:

> On Wed, Feb 21, 2018, at 13:49, Peter Bourgon wrote:
> > > If not,  do I maintain separate /v2 and /v3 trees in my directory and
> copy/paste changes between them when I want to release security fixes as a
> point release?
> >
> > Yes, this is what vgo expects.
>
> This (and the other alternatives) seem like they break most common source
> control work flows to me. Any time we force users to change their workflow,
> I suspect we risk having to back track later. Even in cases where it may be
> better (eg. GOPATH which, like many people, I fought against when I first
> started using Go, but later came to love) if you force developers to
> drastically change their work flow, many of them will either push back, or,
> if it's only convention as this is, simply won't do it.
>
> —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.
>

-- 
You received this message because you are subscribed to the Google 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 += Package Versioning

[Henrik Johansson]

Actually it seems viper imports it with lower case.
I don't remember if import paths are to be considered different if they
only differ in case.


ons 21 feb. 2018 kl 09:04 skrev Henrik Johansson <dahankz...@gmail.com>:

> I am currently running `vgo build` on a decent sized project that has a
> few dependencies.
>
> It bailed on import case it seems:
>
> import "github.com/spf13/jwalterweatherman": module path of repo is
> github.com/spf13/jWalterWeatherman, not github.com/spf13/jwalterweatherman
> (wrong case)
>
> This is a transitive dep and it seems it indeed mixed upper and lower case.
> Does vgo assume lower case?
>
>
> ons 21 feb. 2018 kl 06:46 skrev <je...@samsara.com>:
>
>> Two more use cases of vendor that I would like to keep:
>> - A single audit trail for all go code going into production binaries in
>> a git log.
>> - A single place to enforce upgrades for multiple binaries in a monorepo.
>> Perhaps a top-level meta-module could do the trick?
>>
>> On Tuesday, February 20, 2018 at 6:42:50 PM UTC-8, Dominik Honnef wrote:
>>
>>> Hi,
>>>
>>> I'd like your input on two concern I have, one as a tool developer and
>>> one with regard to reproducible builds.
>>>
>>> With go and go get, it is expected that code will not compile until
>>> all dependencies have been explicitly downloaded. Hence, it is
>>> acceptable for tools such as staticcheck to also fail if dependencies
>>> are not present. Vgo seems to change this, by promising the user that
>>> dependencies will be automatically downloaded. Running `vgo build` at
>>> any point will "just work". Tools, however, do not have this luxury,
>>> for multiple reasons:
>>>
>>> - Multiple tools may run in parallel, either via helpers such as
>>> gometalinter, or simply because editors like Emacs launch multiple
>>> tools at once, for example when saving a file. This is likely prone to
>>> race conditions. File locking may be an option, but file locking is
>>> known to cause erratic problems on networked file systems, or be
>>> outright unsupported.
>>> - Fetching the dependencies, e.g. via 'vgo build', has the side-effect
>>> of modifying the go.mod file. This is probably unacceptable for tools
>>> that are run automatically, without the user's express wish to add new
>>> dependencies to the go.mod file.
>>> - If we do find a solution to these two problems, we'd probably still
>>> want a 'vgo get' (with no arguments), to just fetch the dependencies,
>>> without also incurring a costly build.
>>>
>>> In my opinion, tools should behave as closely as possible to (v)go
>>> build, so that users can operate on a single set of expectations.
>>>
>>> My second concern is regarding the promise of getting rid of the
>>> vendor directory. Reproducible builds not only depend on versioning,
>>> but also on ensuring that code doesn't go away, be it due to server
>>> downtime or more permanent reasons. Vendoring makes this rather easy:
>>> add your dependencies to vendor and commit them, and your project is
>>> now self-contained. Vgo seems to discourage this practice. Can you
>>> suggest an alternative that is as straightforward as vendoring? All
>>> other solutions - which amount to various forms of proxies and mirrors
>>> - are significantly more laboursome.
>>>
>>> I have noticed that currently, vgo downloads dependencies into GOPATH.
>>> Are there any plans to instead store them with the module itself,
>>> possibly in a way that facilitates committing them to version control?
>>>
>>> On Tue, Feb 20, 2018 at 6:20 PM, Russ Cox <r...@golang.org> wrote:
>>> > Hi everyone,
>>> >
>>> > I have a new blog post you might be interested in.
>>> > https://research.swtch.com/vgo.
>>> >
>>> > I'll try to watch this thread to answer any questions.
>>> >
>>> > Best,
>>> > Russ
>>> >
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed 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] Go += Package Versioning

[Henrik Johansson]

I am currently running `vgo build` on a decent sized project that has a few
dependencies.

It bailed on import case it seems:

import "github.com/spf13/jwalterweatherman": module path of repo is
github.com/spf13/jWalterWeatherman, not github.com/spf13/jwalterweatherman
(wrong case)

This is a transitive dep and it seems it indeed mixed upper and lower case.
Does vgo assume lower case?


ons 21 feb. 2018 kl 06:46 skrev :

> Two more use cases of vendor that I would like to keep:
> - A single audit trail for all go code going into production binaries in a
> git log.
> - A single place to enforce upgrades for multiple binaries in a monorepo.
> Perhaps a top-level meta-module could do the trick?
>
> On Tuesday, February 20, 2018 at 6:42:50 PM UTC-8, Dominik Honnef wrote:
>
>> Hi,
>>
>> I'd like your input on two concern I have, one as a tool developer and
>> one with regard to reproducible builds.
>>
>> With go and go get, it is expected that code will not compile until
>> all dependencies have been explicitly downloaded. Hence, it is
>> acceptable for tools such as staticcheck to also fail if dependencies
>> are not present. Vgo seems to change this, by promising the user that
>> dependencies will be automatically downloaded. Running `vgo build` at
>> any point will "just work". Tools, however, do not have this luxury,
>> for multiple reasons:
>>
>> - Multiple tools may run in parallel, either via helpers such as
>> gometalinter, or simply because editors like Emacs launch multiple
>> tools at once, for example when saving a file. This is likely prone to
>> race conditions. File locking may be an option, but file locking is
>> known to cause erratic problems on networked file systems, or be
>> outright unsupported.
>> - Fetching the dependencies, e.g. via 'vgo build', has the side-effect
>> of modifying the go.mod file. This is probably unacceptable for tools
>> that are run automatically, without the user's express wish to add new
>> dependencies to the go.mod file.
>> - If we do find a solution to these two problems, we'd probably still
>> want a 'vgo get' (with no arguments), to just fetch the dependencies,
>> without also incurring a costly build.
>>
>> In my opinion, tools should behave as closely as possible to (v)go
>> build, so that users can operate on a single set of expectations.
>>
>> My second concern is regarding the promise of getting rid of the
>> vendor directory. Reproducible builds not only depend on versioning,
>> but also on ensuring that code doesn't go away, be it due to server
>> downtime or more permanent reasons. Vendoring makes this rather easy:
>> add your dependencies to vendor and commit them, and your project is
>> now self-contained. Vgo seems to discourage this practice. Can you
>> suggest an alternative that is as straightforward as vendoring? All
>> other solutions - which amount to various forms of proxies and mirrors
>> - are significantly more laboursome.
>>
>> I have noticed that currently, vgo downloads dependencies into GOPATH.
>> Are there any plans to instead store them with the module itself,
>> possibly in a way that facilitates committing them to version control?
>>
>> On Tue, Feb 20, 2018 at 6:20 PM, Russ Cox  wrote:
>> > Hi everyone,
>> >
>> > I have a new blog post you might be interested in.
>> > https://research.swtch.com/vgo.
>> >
>> > I'll try to watch this thread to answer any questions.
>> >
>> > Best,
>> > Russ
>> >
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>>
> > email to golang-nuts...@googlegroups.com.
>>
> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Go 1.10 is released

[Henrik Johansson]

Well, first I'll have a look at it's magic 

On Mon, Feb 19, 2018, 22:06 Rob Pike <r...@golang.org> wrote:

> You could say
>
> export GOCACHE=off
>
> in your bashrc to disable the cache permanently.
>
> -rob
>
>
> On Tue, Feb 20, 2018 at 8:00 AM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
>
>> Ok, good to know. Thanks!
>
>
>>
>> On Mon, Feb 19, 2018, 21:49 Ian Lance Taylor <i...@golang.org> wrote:
>>
>>> On Mon, Feb 19, 2018 at 12:40 PM, Henrik Johansson <dahankz...@gmail.com>
>>> wrote:
>>> > Yes I understand. I was just wondering if the GOCACHE flag is
>>> permanent or
>>> > as a temp safety in case someone encounters a bug in the caching.
>>>
>>> Ah.  We are going to keep the GOCACHE environment variable around,
>>> because it can be used not only to disable the cache but to set the
>>> cache's location.
>>>
>>> Ian
>>>
>>> > On Mon, Feb 19, 2018, 21:35 Ian Lance Taylor <i...@golang.org> wrote:
>>> >>
>>> >> On Mon, Feb 19, 2018 at 12:08 PM, Henrik Johansson <
>>> dahankz...@gmail.com>
>>> >> wrote:
>>> >> > Ah, that's not what I meant but GOCACHE var itself and if it will be
>>> >> > permanent as a way to disable the cache.
>>> >>
>>> >> Sorry, I'm not sure exactly what you are saying.  There is no way to
>>> >> permanently disable the cache, other than always setting the GOCACHE
>>> >> environment variable every time you run the go tool.
>>> >>
>>> >> Ian
>>> >>
>>> >> > On Mon, Feb 19, 2018, 21:00 Ian Lance Taylor <i...@golang.org>
>>> wrote:
>>> >> >>
>>> >> >> On Sun, Feb 18, 2018 at 11:00 PM, Henrik Johansson
>>> >> >> <dahankz...@gmail.com>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> > Why I wondered was because to build script (a tiny settings file
>>> >> >> > really)
>>> >> >> > for
>>> >> >> > Archlinux uses this flag to build it's Go packages.
>>> >> >> > Is it available as a paranoia "i really need all the tests run"?
>>> Will
>>> >> >> > it
>>> >> >> > be
>>> >> >> > removed later on?
>>> >> >>
>>> >> >> Sorry, I don't know.  I don't know who wrote that script or why it
>>> sets
>>> >> >> GOCACHE.
>>> >> >>
>>> >> >> Ian
>>> >> >>
>>> >> >>
>>> >> >> > sön 18 feb. 2018 kl 23:04 skrev Ian Lance Taylor <
>>> i...@golang.org>:
>>> >> >> >>
>>> >> >> >> On Sun, Feb 18, 2018 at 11:22 AM, Henrik Johansson
>>> >> >> >> <dahankz...@gmail.com>
>>> >> >> >> wrote:
>>> >> >> >> > The GOCACHE variable. What is it's effect when building Go
>>> itself?
>>> >> >> >> > It doesn't disable test caching when using the resulting go
>>> tools
>>> >> >> >> > right?
>>> >> >> >>
>>> >> >> >> Right.
>>> >> >> >>
>>> >> >> >> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] Re: Go 1.10 is released

[Henrik Johansson]

Ok, good to know. Thanks!

On Mon, Feb 19, 2018, 21:49 Ian Lance Taylor <i...@golang.org> wrote:

> On Mon, Feb 19, 2018 at 12:40 PM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > Yes I understand. I was just wondering if the GOCACHE flag is permanent
> or
> > as a temp safety in case someone encounters a bug in the caching.
>
> Ah.  We are going to keep the GOCACHE environment variable around,
> because it can be used not only to disable the cache but to set the
> cache's location.
>
> Ian
>
> > On Mon, Feb 19, 2018, 21:35 Ian Lance Taylor <i...@golang.org> wrote:
> >>
> >> On Mon, Feb 19, 2018 at 12:08 PM, Henrik Johansson <
> dahankz...@gmail.com>
> >> wrote:
> >> > Ah, that's not what I meant but GOCACHE var itself and if it will be
> >> > permanent as a way to disable the cache.
> >>
> >> Sorry, I'm not sure exactly what you are saying.  There is no way to
> >> permanently disable the cache, other than always setting the GOCACHE
> >> environment variable every time you run the go tool.
> >>
> >> Ian
> >>
> >> > On Mon, Feb 19, 2018, 21:00 Ian Lance Taylor <i...@golang.org> wrote:
> >> >>
> >> >> On Sun, Feb 18, 2018 at 11:00 PM, Henrik Johansson
> >> >> <dahankz...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> > Why I wondered was because to build script (a tiny settings file
> >> >> > really)
> >> >> > for
> >> >> > Archlinux uses this flag to build it's Go packages.
> >> >> > Is it available as a paranoia "i really need all the tests run"?
> Will
> >> >> > it
> >> >> > be
> >> >> > removed later on?
> >> >>
> >> >> Sorry, I don't know.  I don't know who wrote that script or why it
> sets
> >> >> GOCACHE.
> >> >>
> >> >> Ian
> >> >>
> >> >>
> >> >> > sön 18 feb. 2018 kl 23:04 skrev Ian Lance Taylor <i...@golang.org
> >:
> >> >> >>
> >> >> >> On Sun, Feb 18, 2018 at 11:22 AM, Henrik Johansson
> >> >> >> <dahankz...@gmail.com>
> >> >> >> wrote:
> >> >> >> > The GOCACHE variable. What is it's effect when building Go
> itself?
> >> >> >> > It doesn't disable test caching when using the resulting go
> tools
> >> >> >> > right?
> >> >> >>
> >> >> >> Right.
> >> >> >>
> >> >> >> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 1.10 is released

[Henrik Johansson]

Yes I understand. I was just wondering if the GOCACHE flag is permanent or
as a temp safety in case someone encounters a bug in the caching.

On Mon, Feb 19, 2018, 21:35 Ian Lance Taylor <i...@golang.org> wrote:

> On Mon, Feb 19, 2018 at 12:08 PM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > Ah, that's not what I meant but GOCACHE var itself and if it will be
> > permanent as a way to disable the cache.
>
> Sorry, I'm not sure exactly what you are saying.  There is no way to
> permanently disable the cache, other than always setting the GOCACHE
> environment variable every time you run the go tool.
>
> Ian
>
> > On Mon, Feb 19, 2018, 21:00 Ian Lance Taylor <i...@golang.org> wrote:
> >>
> >> On Sun, Feb 18, 2018 at 11:00 PM, Henrik Johansson <
> dahankz...@gmail.com>
> >> wrote:
> >> >
> >> > Why I wondered was because to build script (a tiny settings file
> really)
> >> > for
> >> > Archlinux uses this flag to build it's Go packages.
> >> > Is it available as a paranoia "i really need all the tests run"? Will
> it
> >> > be
> >> > removed later on?
> >>
> >> Sorry, I don't know.  I don't know who wrote that script or why it sets
> >> GOCACHE.
> >>
> >> Ian
> >>
> >>
> >> > sön 18 feb. 2018 kl 23:04 skrev Ian Lance Taylor <i...@golang.org>:
> >> >>
> >> >> On Sun, Feb 18, 2018 at 11:22 AM, Henrik Johansson
> >> >> <dahankz...@gmail.com>
> >> >> wrote:
> >> >> > The GOCACHE variable. What is it's effect when building Go itself?
> >> >> > It doesn't disable test caching when using the resulting go tools
> >> >> > right?
> >> >>
> >> >> Right.
> >> >>
> >> >> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 1.10 is released

[Henrik Johansson]

Ah, that's not what I meant but GOCACHE var itself and if it will be
permanent as a way to disable the cache.

On Mon, Feb 19, 2018, 21:00 Ian Lance Taylor <i...@golang.org> wrote:

> On Sun, Feb 18, 2018 at 11:00 PM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> >
> > Why I wondered was because to build script (a tiny settings file really)
> for
> > Archlinux uses this flag to build it's Go packages.
> > Is it available as a paranoia "i really need all the tests run"? Will it
> be
> > removed later on?
>
> Sorry, I don't know.  I don't know who wrote that script or why it sets
> GOCACHE.
>
> Ian
>
>
> > sön 18 feb. 2018 kl 23:04 skrev Ian Lance Taylor <i...@golang.org>:
> >>
> >> On Sun, Feb 18, 2018 at 11:22 AM, Henrik Johansson <
> dahankz...@gmail.com>
> >> wrote:
> >> > The GOCACHE variable. What is it's effect when building Go itself?
> >> > It doesn't disable test caching when using the resulting go tools
> right?
> >>
> >> Right.
> >>
> >> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: All Forms of Wishful Generics

[Henrik Johansson]

I disagree that generics would decrease readability at the call site.
Perhaps within the library where it is used but maybe not even there. The
only complexity is within the compiler and other internals. This is not
irrelevant by far but the carte blanche "generics is bad" is most often
hyperbole.

I can also "do without" generics and in fact even though Go lacks it I
prefer Go to all other languages that I know. I still would appreciate a
generics version in Go's spirit.

On Mon, Feb 19, 2018, 16:06 Ignazio Di Napoli  wrote:

>
> On Monday, February 19, 2018 at 4:04:12 PM UTC+1, Ignazio Di Napoli wrote:
>>
>> data2 := found.(float32)   // THIS PANICS AT RUNTIME, data2 is int
>>
>
> Sorry, found is 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.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Go 1.10 is released

[Henrik Johansson]

Thx,

Why I wondered was because to build script (a tiny settings file really)
for Archlinux uses this flag to build it's Go packages.
Is it available as a paranoia "i really need all the tests run"? Will it be
removed later on?



sön 18 feb. 2018 kl 23:04 skrev Ian Lance Taylor <i...@golang.org>:

> On Sun, Feb 18, 2018 at 11:22 AM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > The GOCACHE variable. What is it's effect when building Go itself?
> > It doesn't disable test caching when using the resulting go tools right?
>
> Right.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 1.10 is released

[Henrik Johansson]

The GOCACHE variable. What is it's effect when building Go itself?
It doesn't disable test caching when using the resulting go tools right?

sön 18 feb. 2018 kl 19:55 skrev Lucio :

>
>
> On Sunday, 18 February 2018 04:20:39 UTC+2, Dmitriy Cherchenko wrote:
>>
>> I like how the Go team isn't trying to support very old operating
>> systems. We should focus on modern systems and expect people to try to stay
>> up to date. Thank you!
>>
>> And be restricted to shrinking bio-diversity. How sad that people may
> perceive this as an asset!
>
> Lucio.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google 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] Extensive Go resources for CS101

[Henrik Johansson]

This is good news in so many ways! Finally a useable language in university
courses! Sure everyone could use a good lisp now and then but for most
engineering getting to useable stuff fast is very important.

And there is a lot of stuff there! Thank you!

lör 3 feb. 2018 kl 11:18 skrev Stefan Nilsson :

> At KTH in Stockholm we’ve been using Go to teach the basics of concurrent
> programming for a few years, and we might go ahead and use Go for Computer
> Science 101 as well. Preparing for this, I’ve put together a fairly
> extensive set of articles, cheat sheets and how to’s at
>
> http://yourbasic.org/golang/
>
> It’s freely available under a CC license, and I hope it can be of use to
> some of you as well.
>
> --
> You received this message because you are subscribed to the Google 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] Rate controlling the Go http server

[Henrik Johansson]

Happy to help!

The limit can be anything from the link above or something more advanced
that Jesper suggested. The skeleton could be as outlined above however.

On Fri, Feb 2, 2018, 15:40 mrx <patrik@gmail.com> wrote:

> On Fri, Feb 2, 2018 at 1:28 PM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
>
>> You can either use one of the existing other routers that have meddleware
>> support or you could wrap your handlers in another handler much like this:
>>
>> handle("/foo",wrapHandler(rateLimiter, realHandler))
>>
>> func wrapHandler(limit *ARateLimiter, handler func(http.ResponseWriter,
>> *http.Request)) func(http.ResponseWriter, *http.Request){
>>   return func(w http.ResponseWriter, r *http.Request) {
>>limit.Aquire() //Or however you use the limiter
>>handle(w,r)
>>  }
>> }
>>
>> Very rudimentary and simplified but could perhaps work. You can wrap any
>> handler in the same way with either a shared limiter or one per call or any
>> combination.
>>
>
> Feels like your limit parameter is simply a semaphore to me. I'll try that
> for now. Thanks a lot for your help, it was most illuminating!
>
> // Patrik
>

-- 
You received this message because you are subscribed to the Google 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] Rate controlling the Go http server

[Henrik Johansson]

You can either use one of the existing other routers that have meddleware
support or you could wrap your handlers in another handler much like this:

handle("/foo",wrapHandler(rateLimiter, realHandler))

func wrapHandler(limit *ARateLimiter, handler func(http.ResponseWriter,
*http.Request)) func(http.ResponseWriter, *http.Request){
  return func(w http.ResponseWriter, r *http.Request) {
   limit.Aquire() //Or however you use the limiter
   handle(w,r)
 }
}

Very rudimentary and simplified but could perhaps work. You can wrap any
handler in the same way with either a shared limiter or one per call or any
combination.


fre 2 feb. 2018 kl 13:06 skrev Patrik Iselind :

>
> Den fredag 2 februari 2018 kl. 11:50:43 UTC+1 skrev Jesper Louis Andersen:
>>
>> A simple solution is to have a channel of type struct{} of some bound,
>> say 10. A process only gives service as long as it can pull a message from
>> the channel.
>>
>
> How would i hook in such a channel in the http server? Wouldn't a channel
> of type interface{} be better?
>
>
>> More advanced solutions include handling the channel as a token bucket
>> and regulating it to have a drip-rate.
>>
>
> I would prefer simple over complex in this instance.
>
>
>>
>> Even more advanced solutions sample your system and slows the drip feed
>> when it is overloaded with resources.
>>
>> You might also consider pushback and queuing. If you are overloaded, you
>> have to tell the caller to stop sending requests for a while.
>>
>> Consider using a model such as CoDel (Controlled Delay) on your queues.
>>
>
> pushback, queuing and CoDel might be good ideas further down the line for
> my project. I'll keep those in mind, thanks!
>
>
> // Patrik
>
> --
> You received this message because you are subscribed to the Google 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] Rate controlling the Go http server

[Henrik Johansson]

I guess a middleware wrapping any of the available rate limiters
https://godoc.org/?q=rate+limit should do the trick?

fre 2 feb. 2018 kl 11:30 skrev Patrik Iselind :

> Hi,
>
> If i define a webserver as such (taken from the docs)
>
> http.Handle("/foo", fooHandler)
>
> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
>   fmt.Fprintf(w, "Hello, %q", html.EscapeString(r.URL.Path))
> })
>
> log.Fatal(http.ListenAndServe(":8080", nil))
>
>
> How do i control how many simultaneous requests my server may handle?
>
> As i understand it, the handlers get spawned off as separate go routines.
> I'm looking for a way to limit the number of such go routines.
>
> I would like to limit the effects of getting a massive storm of requests
> in a short amount of time which might chew up all RAM/CPU.
>
> // Patrik
>
>
> --
> You received this message because you are subscribed to the Google 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: Upcoming Go protobuf release

[Henrik Johansson]

Surely these issues already exist in gogo-protobuf? How are they handled
there?

On Thu, Feb 1, 2018, 08:28 'Jisi Liu' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> This is not Java specific. I just used Java as an example. For most
> protobuf implementations, there is a contract between the runtime and
> generated code which is not meant to be public. e.g. In go-protobuf,
> runtime expects the generated classes define some internal fields, like
> XXX_unrecognized, and  XXX_sizecache.
>
> If we are moving from table-driven to codegen, then I guess there will be
> more contracts between the runtime and generated code, and potentially
> introduce contracts also between the containing message and embedded
> message fields - you probably want to extract duplicate methods into
> runtime to save code size, and the generate code needs to deal with
> submessages itself.  This is my primary concern.
>
> In a single repo development model, someone can change such contract as
> long as they change the protoc-gen and the runtime library at the same
> time. However, in open source, such change can cause dependency-hell
> issues as the different
> versions of generated protobufs are no-longer compatible with each other
> and/or with the runtime. With a more tightly coupled model, we are more
> prone to such issue.
>
> One way to solve this is to make the runtime support all the previous
> versions of the contract indefinitely and be always backward compatible.
> Then users can switch to the newest runtime to support all the old
> libraries. We are following this approach in protobuf-java 3.x, which
> causes lots of dev overhead. I'm a bit worried that we would need to do the
> same for Go, if we go with the code-gen approach.
>
>
> On Wed, Jan 31, 2018 at 10:25 PM Walter Schulze 
> wrote:
>
>> Could we perhaps get a code snippet example that non java programmers can
>> follow.
>>
>> PS
>>
>> When I previously referred to java programmers as real software
>> developers, I didn't add some much needed context.
>>
>> Sometimes in this java dominated world I personally don't feel like a
>> real software developer.
>>
>> On Wed, 31 Jan 2018, 21:44 liujisi via golang-nuts, <
>> golang-nuts@googlegroups.com> wrote:
>>
>>>
>>>
>>> On Wednesday, January 31, 2018 at 11:20:31 AM UTC-8, Walter Schulze
>>> wrote:
>>>
 Hi JT please see my inline replies.

 On Wed, 31 Jan 2018 at 19:05  wrote:

> Thank you, Walter, for your support.
>
> > gogo/protobuf is disappointed that golang/protobuf still thinks that
> runtime reflection is an efficient way of serializing structures.
>
> The table-driven implementation avoids reflect in the fast and common
> path. Instead, are you referring to the fact that we don't perform
> full-code generation of Marshal/Unmarshal like what gogo/protobuf does? We
> are aware that full-code generation will often out-perform the 
> table-driven
> approach we took. However, full code-generation drastically bloats the
> binary size when you have many proto messages linked in. Keeping the 
> binary
> size smaller was an important design decision for us and seemed to be a
> better default.
>

 Yes, I was referring to the speed of code generation over runtime
 reflection.
 What I struggle to understand is why the optimize_for file option that
 is part of proto 2 and 3 is not considered by golang/protobuf as a way to
 specify when code generation should be used over runtime reflection.
 This seems to work for most other languages, including Java, which I
 heard is quite popular among real software developers.

>>>
>>> Note that the code-generation approach used by other languages (mostly
>>> C++/Java) has its own problem. Mostly because of the tight coupling among
>>> generated code, runtime and embedded sub messages (generated by a different
>>> party using a different version of protoc). These problem don't exist
>>> inside of google as we use a single repo build system, but it cause
>>> significant issues in opensource. For instance, Hadoop is still shipping
>>> protobuf v2.5 generated code which is incompatible with later version of
>>> protobufs. All the projects using Hadoop are then version locked to v2.5,
>>> as an upgrade in any project (including Hadoop itself) will break the
>>> build. Version upgrade can only happen when all the transitive dependency
>>> closure upgrade together atomically.
>>>
>>> We solve this problem in protobuf-java v3.0+ by introducing ABI
>>> backward/forward compatibility guarantees on generated code and runtime.
>>> However, this introduced lots of overhead on code maintenance, reduced
>>> development velocity and limited the change we could do.  We are now
>>> solving the issue by introduce table driven to Java. The recent benchmark
>>> result showed 

Re: [go-nuts] Re: How golang garbage collector works

[Henrik Johansson]

I think this one by Rick Hudson is very good as well.
https://www.infoq.com/presentations/go-gc-performance

tors 11 jan. 2018 kl 18:38 skrev :

> Hi!
>
> Currently go uses concurrent mark'n'sweep. Best talk about gc in go and
> theory:
> https://pusher.com/sessions/meetup/the-realtime-guild/golangs-realtime-garbage-collector
> Also you can read chapter 15 in GC handbook:
> http://gchandbook.org/contents.html
>
>
> четверг, 11 января 2018 г., 18:50:24 UTC+3 пользователь golangguy написал:
>
>> Hi
>>
>> I am new to golang, and had background in C/C++ , can you some one give
>> me information/explanation about how garbage collectors in golang works ?
>>
>> 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] The o.done access on the once.Do function

[Henrik Johansson]

Surely single goroutine scenarios are trivial? Anything else would be a
compiler bug. In multiple goroutine scenarios a lock must be held or some
of the atomic functions are needed. Any other use that "works" are by
accident say on x86 or some other stricter arch. I am no expert in this but
surely hope this is true because much of my code depends on it...

On Fri, Dec 29, 2017, 09:57 Caleb Spare  wrote:

> > I believe that program will always print 2, however when you bring
> multiple Goroutines into the mix, I’m less sure.
>
> I'm using examples without goroutines because the crux of our
> discussion, as I understand it, is whether a plain read ('if o.done ==
> 0') will read the result of an atomic write
> ('atomic.StoreUint32(, 1)') given that there is a
> happens-before relationship between them.
>
> The simplest kind of happens-before relationship is that between
> sequential lines of straight-line code in a single goroutine. If you
> agree that the mutexes imply a happens-before relationship between the
> atomic write and the plain read, then we can simplify the discussion
> by only considering sequential code in a single goroutine.
>
> Regarding the sequential, single-goroutine example code: for my first
> example with atomic.StoreUint32
> (https://play.golang.org/p/fdf8VeJ98Jv), you wrote
>
> > I agree it should print 2, but my reading of the memory model and
> > https://github.com/golang/go/issues/5045 doesn't give me any concrete
> > guarantee that it must. This is why i'm not sure about the
> > interactions between atomic and non atomic loads.
>
> but for the second example with a non-atomic store function
> (https://play.golang.org/p/gk3c6X_JdmQ), you wrote
>
> > I believe that program will always print 2
>
> What's the distinction you see between them?
>
> --
> You received this message because you are subscribed to the Google 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] The o.done access on the once.Do function

[Henrik Johansson]

Isn't the lock operation an memory acquire operation that means that the
next load of the done field needs to be loaded from memory?

Perhaps it is not stated in the memory model exactly but this seems safe.

On Fri, Dec 29, 2017, 08:11 Dave Cheney  wrote:

>
>
> On 29 Dec 2017, at 18:01, Caleb Spare  wrote:
>
> >>> This expression:
> >>>
> >>> atomic.StoreUint32(, 1)
> >>>
> >>> does not just take the address of o.done. It also executes the
> >>> StoreUint32 function, which is defined by the sync/atomic
> >>> documentation to behave like '*o.done = 1'; i.e., it alters the value
> >>> of o.done.
> >>
> >>
> >> Respectfully I disagree, it store the value 1 at the memory address
> 
> >> It has no defined effect on other occurrences of o.done in this, or
> other
> >> goroutines if they have already loaded o.done.
> >>
> >> I agree that i'm still talking about registers and inlining; but if
> there
> >> were no registers, inlining, caches, or other things which are not
> specified
> >> by the language, then there would be no data races. So here we are.
> >
> > Does your argument rely on atomic.StoreUint32 being special, or would
> > you also say that this program is not defined to always print 2?
>
> I believe that program will always print 2, however when you bring
> multiple Goroutines into the mix, I’m less sure.
>
> >
> > https://play.golang.org/p/gk3c6X_JdmQ
>
> --
> You received this message because you are subscribed to the Google 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: [urgent] need aguments to justify use of Go for a scientific application

[Henrik Johansson]

I have a vague memory of +Rob Pike  tweeting something about
astronomy or perhaps an observatory a few months ago.
Perhaps there was no programming involved but if so I imagine Go is safe
bet.

But building pipelines using something like Pachyderm would allow for a
very polyglot "use the tool that fits in each part" approach.


ons 6 dec. 2017 kl 11:43 skrev Volker Dobler :

> I know about https://go-hep.org probably Sebastien can elaborate more
> if and how it is used at CERN.
>
> V.
>
>
> On Wednesday, 6 December 2017 10:56:01 UTC+1, Christophe Meessen wrote:
>>
>> Hello,
>>
>> I'm a computer scientist in charge of developing an image processing
>> pipeline for telescope images.
>> It will also have a web server and DB connection.
>>
>> The project is going through reviews by external experts, and the problem
>> I'm facing is that my proposal to use Go is about to be rejected.
>>
>> The main opposing arguments are
>> - everybody uses python in astrophysics
>> - it is very easy to find someone who knows python
>> - risk that I, sole Go programmer, might become unavailable
>>
>> I would have the same arguments if I was project leader and unfamiliar
>> with Go.
>>
>> The counter arguments I found so far are that
>> - Go is simpler and safer than Python
>> - I learned Go in a week-end
>>
>> The problem is that they don't convince people who don't know Go, are not
>> experienced software developers, and don't want to do the due diligence.
>> It's the usual inertia to change.
>>
>> What other arguments could I use ?
>>
>> Do you know other significant scientific experiments that have adopted Go
>> ?
>>
>>
>>
>> I have found this github project.
>> https://github.com/indigo-astronomy/indigo
>> INDI is a well known Python Observatory Control System.
>> INDIGO is its translation into Go.
>>
>> I have also found SciPipe https://github.com/scipipe.
>> It is a Go pipeline framework used in scientific applications.
>>
>>
>> --
> You received this message because you are subscribed to the Google 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: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

No problems! If I can get a beta running I'll revisit this thread.

Cheers,

On Tue, Dec 5, 2017, 19:41 Rick Hudson <r...@golang.org> wrote:

> Henrik,
> Thanks for the kind offer but there isn't much the runtime team can do
> with the logs since 1.9 isn't likely to be changed due to this issue.
>
>
>
> On Tue, Dec 5, 2017 at 10:43 AM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
>
>> I would gladly help with this but afaik Heroku only makes stable versions
>> available:
>> https://github.com/heroku/heroku-buildpack-go/blob/master/data.json
>> I guess I could deploy a docker container but I don't know if it changes
>> everything and I doubt I have time before christmas at least.
>>
>> Maybe someone more versed in Herokus Go support can chime in on if it is
>> possible.
>>
>> I will provide the logs from tonight though. Do you want them zipped here
>> in the thread?
>>
>>
>> tis 5 dec. 2017 kl 15:37 skrev Rick Hudson <r...@golang.org>:
>>
>>> Glad to have helped. The runtime team would be interested in seeing what
>>> these pauses look like in the beta. If you have the time could you send
>>> them to us after the beta comes out.
>>>
>>>
>>> On Tue, Dec 5, 2017 at 9:06 AM, Henrik Johansson <dahankz...@gmail.com>
>>> wrote:
>>>
>>>> Ok so it's not bad, thats good!
>>>>
>>>> The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
>>>> (Beta) provides.
>>>> These must be sums in the given graph bucket which may for a 24H period
>>>> add up to the high numbers I guess.
>>>>
>>>> I will let it run over night and see what it looks like tomorrow, thx
>>>> for your thoughts on this!
>>>>
>>>> tis 5 dec. 2017 kl 14:58 skrev <r...@golang.org>:
>>>>
>>>>> The wall clock is the first set of numbers, the second set is CPU. So
>>>>> 8P running for 8ms wall clock will result in 64ms CPU. The word "wall" was
>>>>> dropped to keep the line short.
>>>>>
>>>>> There will be a beta out in the proverbial next few days that could
>>>>> help reduce even these STW times. The original post talked about 20 second
>>>>> and 400 and 900 ms pauses. From what I'm seeing here it is hard to
>>>>> attribute them to GC STW pauses.
>>>>>
>>>>> Also the GC is taking up (a rounded) 0% of the CPU which is pretty
>>>>> good (insert fancy new emoji).  It is also doing it with a budget of 10 or
>>>>> 11 MBtyes on a machine that likely has 8 GB of Ram. To further test 
>>>>> whether
>>>>> this is a GC issue or not try increasing GOGC until the MB goal on the
>>>>> gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x 
>>>>> or
>>>>> 100x and if your tail latency is a GC problem the 99%tile latency numbers
>>>>> will become 99.9%tile or 99.99%tile numbers.
>>>>>
>>>>> On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson
>>>>> wrote:
>>>>>
>>>>>> I am watching with childlike fascination...
>>>>>> This is interesting perhaps:
>>>>>>
>>>>>> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms
>>>>>> cpu, 8->8->4 MB, 9 MB goal, 8 P
>>>>>> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0
>>>>>> ms cpu, 9->9->5 MB, 10 MB
>>>>>> <https://maps.google.com/?q=5+MB,+10+MB=gmail=g> goal,
>>>>>> 8 P
>>>>>>
>>>>>> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms
>>>>>> cpu, 10->11->4 MB, 11 MB
>>>>>> <https://maps.google.com/?q=4+MB,+11+MB=gmail=g> goal,
>>>>>> 8 P
>>>>>>
>>>>>> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms
>>>>>> cpu, 8->9->5 MB, 9 MB goal, 8 P
>>>>>> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
>>>>>> 9->10->5 MB, 10 MB
>>>>>> <https://maps.google.com/?q=5+MB,+10+MB=gmail=g> goal,
>>>>>> 8 P
>>>>>>
>>>>>> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>>>>>>
>>>>>>
>>>>>&

Re: [go-nuts] Re: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

I would gladly help with this but afaik Heroku only makes stable versions
available:
https://github.com/heroku/heroku-buildpack-go/blob/master/data.json
I guess I could deploy a docker container but I don't know if it changes
everything and I doubt I have time before christmas at least.

Maybe someone more versed in Herokus Go support can chime in on if it is
possible.

I will provide the logs from tonight though. Do you want them zipped here
in the thread?


tis 5 dec. 2017 kl 15:37 skrev Rick Hudson <r...@golang.org>:

> Glad to have helped. The runtime team would be interested in seeing what
> these pauses look like in the beta. If you have the time could you send
> them to us after the beta comes out.
>
>
> On Tue, Dec 5, 2017 at 9:06 AM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
>
>> Ok so it's not bad, thats good!
>>
>> The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
>> (Beta) provides.
>> These must be sums in the given graph bucket which may for a 24H period
>> add up to the high numbers I guess.
>>
>> I will let it run over night and see what it looks like tomorrow, thx for
>> your thoughts on this!
>>
>> tis 5 dec. 2017 kl 14:58 skrev <r...@golang.org>:
>>
>>> The wall clock is the first set of numbers, the second set is CPU. So 8P
>>> running for 8ms wall clock will result in 64ms CPU. The word "wall" was
>>> dropped to keep the line short.
>>>
>>> There will be a beta out in the proverbial next few days that could help
>>> reduce even these STW times. The original post talked about 20 second and
>>> 400 and 900 ms pauses. From what I'm seeing here it is hard to attribute
>>> them to GC STW pauses.
>>>
>>> Also the GC is taking up (a rounded) 0% of the CPU which is pretty good
>>> (insert fancy new emoji).  It is also doing it with a budget of 10 or 11
>>> MBtyes on a machine that likely has 8 GB of Ram. To further test whether
>>> this is a GC issue or not try increasing GOGC until the MB goal on the
>>> gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x or
>>> 100x and if your tail latency is a GC problem the 99%tile latency numbers
>>> will become 99.9%tile or 99.99%tile numbers.
>>>
>>> On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson wrote:
>>>
>>>> I am watching with childlike fascination...
>>>> This is interesting perhaps:
>>>>
>>>> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms cpu,
>>>> 8->8->4 MB, 9 MB goal, 8 P
>>>> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms
>>>> cpu, 9->9->5 MB, 10 MB
>>>> <https://maps.google.com/?q=5+MB,+10+MB=gmail=g> goal, 8
>>>> P
>>>>
>>>> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms
>>>> cpu, 10->11->4 MB, 11 MB
>>>> <https://maps.google.com/?q=4+MB,+11+MB=gmail=g> goal, 8
>>>> P
>>>>
>>>> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu,
>>>> 8->9->5 MB, 9 MB goal, 8 P
>>>> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
>>>> 9->10->5 MB, 10 MB
>>>> <https://maps.google.com/?q=5+MB,+10+MB=gmail=g> goal, 8
>>>> P
>>>>
>>>> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>>>>
>>>>
>>>>
>>>> tis 5 dec. 2017 kl 08:25 skrev Dave Cheney <da...@cheney.net>:
>>>>
>>> Oh yeah, I forgot someone added that a while back. That should work.
>>>>>
>>>>> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson <dahan...@gmail.com>
>>>>> wrote:
>>>>> > So it has to run the program? I thought I saw "logfile" scenario in
>>>>> the
>>>>> > examples?
>>>>> >
>>>>> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
>>>>> > cat stderr.log | gcvis
>>>>> >
>>>>> > I have shuffled the Heroku logs into Papertrail so I should be able
>>>>> to
>>>>> > extract the log lines from there.
>>>>> >
>>>>> >
>>>>> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney <da...@cheney.net>:
>>>>> >>
>>>>> >> Probably not for your scenario, gcviz assumes it can run your
>>>>&

Re: [go-nuts] Re: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

Ok so it's not bad, thats good!

The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
(Beta) provides.
These must be sums in the given graph bucket which may for a 24H period add
up to the high numbers I guess.

I will let it run over night and see what it looks like tomorrow, thx for
your thoughts on this!

tis 5 dec. 2017 kl 14:58 skrev <r...@golang.org>:

> The wall clock is the first set of numbers, the second set is CPU. So 8P
> running for 8ms wall clock will result in 64ms CPU. The word "wall" was
> dropped to keep the line short.
>
> There will be a beta out in the proverbial next few days that could help
> reduce even these STW times. The original post talked about 20 second and
> 400 and 900 ms pauses. From what I'm seeing here it is hard to attribute
> them to GC STW pauses.
>
> Also the GC is taking up (a rounded) 0% of the CPU which is pretty good
> (insert fancy new emoji).  It is also doing it with a budget of 10 or 11
> MBtyes on a machine that likely has 8 GB of Ram. To further test whether
> this is a GC issue or not try increasing GOGC until the MB goal on the
> gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x or
> 100x and if your tail latency is a GC problem the 99%tile latency numbers
> will become 99.9%tile or 99.99%tile numbers.
>
> On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson wrote:
>
>> I am watching with childlike fascination...
>> This is interesting perhaps:
>>
>> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms cpu,
>> 8->8->4 MB, 9 MB goal, 8 P
>> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms
>> cpu, 9->9->5 MB, 10 MB
>> <https://maps.google.com/?q=5+MB,+10+MB=gmail=g> goal, 8 P
>>
>> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms cpu,
>> 10->11->4 MB, 11 MB
>> <https://maps.google.com/?q=4+MB,+11+MB=gmail=g> goal, 8 P
>>
>> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu,
>> 8->9->5 MB, 9 MB goal, 8 P
>> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
>> 9->10->5 MB, 10 MB
>> <https://maps.google.com/?q=5+MB,+10+MB=gmail=g> goal, 8 P
>>
>> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>>
>>
>>
>> tis 5 dec. 2017 kl 08:25 skrev Dave Cheney <da...@cheney.net>:
>>
> Oh yeah, I forgot someone added that a while back. That should work.
>>>
>>> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson <dahan...@gmail.com>
>>> wrote:
>>> > So it has to run the program? I thought I saw "logfile" scenario in the
>>> > examples?
>>> >
>>> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
>>> > cat stderr.log | gcvis
>>> >
>>> > I have shuffled the Heroku logs into Papertrail so I should be able to
>>> > extract the log lines from there.
>>> >
>>> >
>>> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney <da...@cheney.net>:
>>> >>
>>> >> Probably not for your scenario, gcviz assumes it can run your program
>>> >> as a child.
>>> >>
>>>
>> >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson <dahan...@gmail.com>
>>
>>
>>> >> wrote:
>>> >> > I found https://github.com/davecheney/gcvis from +Dave Cheney is
>>> it a
>>> >> > good
>>> >> > choice for inspecting the gc logs?
>>> >> >
>>> >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <dahan...@gmail.com
>>> >:
>>> >> >>
>>> >> >> I have just added the gc tracing and it looks like this more or
>>> less
>>> >> >> all
>>> >> >> the time:
>>> >> >>
>>> >> >> gc 78 @253.095s 0
>>> <https://maps.google.com/?q=@253.095s+0=gmail=g>%:
>>> 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms
>>> >> >> cpu,
>>> >> >> 11->12->4 MB, 12 MB
>>> <https://maps.google.com/?q=4+MB,+12+MB=gmail=g> goal, 8 P
>>> >> >> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock, 0.16+0.19/3.6/1.2+1.3
>>> ms
>>> >> >> cpu,
>>> >> >> 9->9->4 MB, 10 MB
>>> <https://maps.google.com/?q=4+MB,+10+MB=gmail=g> goal, 8 P
>>> >> >> gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock, 0.17+0.27/4.8/

Re: [go-nuts] Re: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

I am watching with childlike fascination...
This is interesting perhaps:

gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms cpu,
8->8->4 MB, 9 MB goal, 8 P
gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms cpu,
9->9->5 MB, 10 MB goal, 8 P

---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms cpu,
10->11->4 MB, 11 MB goal, 8 P

gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu,
8->9->5 MB, 9 MB goal, 8 P
gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
9->10->5 MB, 10 MB goal, 8 P

28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?



tis 5 dec. 2017 kl 08:25 skrev Dave Cheney <d...@cheney.net>:

> Oh yeah, I forgot someone added that a while back. That should work.
>
> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > So it has to run the program? I thought I saw "logfile" scenario in the
> > examples?
> >
> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
> > cat stderr.log | gcvis
> >
> > I have shuffled the Heroku logs into Papertrail so I should be able to
> > extract the log lines from there.
> >
> >
> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney <d...@cheney.net>:
> >>
> >> Probably not for your scenario, gcviz assumes it can run your program
> >> as a child.
> >>
> >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson <dahankz...@gmail.com>
> >> wrote:
> >> > I found https://github.com/davecheney/gcvis from +Dave Cheney is it a
> >> > good
> >> > choice for inspecting the gc logs?
> >> >
> >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <dahankz...@gmail.com
> >:
> >> >>
> >> >> I have just added the gc tracing and it looks like this more or less
> >> >> all
> >> >> the time:
> >> >>
> >> >> gc 78 @253.095s 0
> <https://maps.google.com/?q=@253.095s+0=gmail=g>%:
> 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms
> >> >> cpu,
> >> >> 11->12->4 MB, 12 MB goal, 8 P
> >> >> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock, 0.16+0.19/3.6/1.2+1.3 ms
> >> >> cpu,
> >> >> 9->9->4 MB, 10 MB goal, 8 P
> >> >> gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock, 0.17+0.27/4.8/0.006+18 ms
> >> >> cpu,
> >> >> 8->8->4 MB, 9 MB goal, 8 P
> >> >> gc 81 @253.138s 0%: 0.019+2.3+0.10 ms clock, 0.15+0.73/3.9/3.1+0.81
> ms
> >> >> cpu, 9->9->5 MB, 10 MB goal, 8 P
> >> >>
> >> >> Heroku already reports a SW of 343 ms but I can't find it by manual
> >> >> inspection. I will download the logs later today and try to generate
> >> >> realistic load.
> >> >> What is the overhead of running like this, aside from the obvious
> extra
> >> >> logging?
> >> >> Are there any automatic tools to analyze these logs?
> >> >>
> >> >> lör 2 dec. 2017 kl 22:36 skrev Henrik Johansson <
> dahankz...@gmail.com>:
> >> >>>
> >> >>> I am sorry, I was unclear. The app uses very little ram but the
> >> >>> provisioned available memory is 512 MB.
> >> >>>
> >> >>> I will try to experiment with GC toggles as you suggest and report
> >> >>> back.
> >> >>>
> >> >>> Thx!
> >> >>>
> >> >>>
> >> >>> On Sat, Dec 2, 2017, 22:18 rlh via golang-nuts
> >> >>> <golang-nuts@googlegroups.com> wrote:
> >> >>>>
> >> >>>> Hard telling what it going on. 35MB, even for 1 CPU, seems very
> >> >>>> small.
> >> >>>> Most modern system provision more than 1GB per HW thread though
> I've
> >> >>>> seen
> >> >>>> some provision as little as 512MB. GOGC (SetGCPercent) can be
> adjust
> >> >>>> so that
> >> >>>> the application uses more of the available RAM. Running with
> >> >>>> GODEBUG=gctrace=1 will give you a sense of the GC's view of the
> >> >>>> application.
> >> >>>>
> >> >>>> In any case these kinds of numbers, running on a real systems, and
> >> >>>> duplicatable on tip are worth filing an issue.
> >> >>&g

Re: [go-nuts] Re: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

So it has to run the program? I thought I saw "logfile" scenario in the
examples?

GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
cat stderr.log | gcvis

I have shuffled the Heroku logs into Papertrail so I should be able to
extract the log lines from there.


tis 5 dec. 2017 kl 08:10 skrev Dave Cheney <d...@cheney.net>:

> Probably not for your scenario, gcviz assumes it can run your program
> as a child.
>
> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > I found https://github.com/davecheney/gcvis from +Dave Cheney is it a
> good
> > choice for inspecting the gc logs?
> >
> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <dahankz...@gmail.com>:
> >>
> >> I have just added the gc tracing and it looks like this more or less all
> >> the time:
> >>
> >> gc 78 @253.095s 0%: 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms
> cpu,
> >> 11->12->4 MB, 12 MB goal, 8 P
> >> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock, 0.16+0.19/3.6/1.2+1.3 ms
> cpu,
> >> 9->9->4 MB, 10 MB goal, 8 P
> >> gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock, 0.17+0.27/4.8/0.006+18 ms
> cpu,
> >> 8->8->4 MB, 9 MB goal, 8 P
> >> gc 81 @253.138s 0%: 0.019+2.3+0.10 ms clock, 0.15+0.73/3.9/3.1+0.81 ms
> >> cpu, 9->9->5 MB, 10 MB goal, 8 P
> >>
> >> Heroku already reports a SW of 343 ms but I can't find it by manual
> >> inspection. I will download the logs later today and try to generate
> >> realistic load.
> >> What is the overhead of running like this, aside from the obvious extra
> >> logging?
> >> Are there any automatic tools to analyze these logs?
> >>
> >> lör 2 dec. 2017 kl 22:36 skrev Henrik Johansson <dahankz...@gmail.com>:
> >>>
> >>> I am sorry, I was unclear. The app uses very little ram but the
> >>> provisioned available memory is 512 MB.
> >>>
> >>> I will try to experiment with GC toggles as you suggest and report
> back.
> >>>
> >>> Thx!
> >>>
> >>>
> >>> On Sat, Dec 2, 2017, 22:18 rlh via golang-nuts
> >>> <golang-nuts@googlegroups.com> wrote:
> >>>>
> >>>> Hard telling what it going on. 35MB, even for 1 CPU, seems very small.
> >>>> Most modern system provision more than 1GB per HW thread though I've
> seen
> >>>> some provision as little as 512MB. GOGC (SetGCPercent) can be adjust
> so that
> >>>> the application uses more of the available RAM. Running with
> >>>> GODEBUG=gctrace=1 will give you a sense of the GC's view of the
> application.
> >>>>
> >>>> In any case these kinds of numbers, running on a real systems, and
> >>>> duplicatable on tip are worth filing an issue.
> >>>>
> >>>> On Saturday, December 2, 2017 at 3:02:30 AM UTC-5, Henrik Johansson
> >>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I am befuddled by GC SW times on several seconds (seen 20s once) in
> the
> >>>>> metrics page for our app. There are several things that are strange
> but
> >>>>> perhaps I am misreading it. The same metrics page reports Max Total
> 35 MB
> >>>>> out of which 1 MB s swap the rest RSS. The response times on the
> service is
> >>>>> has 99% ~400 ms which is not good but 95% is ~120 ms usually.
> >>>>> The app reloads an in memory cache as needed using atomic,Value as a
> >>>>> holder and the size is no more than a few thousand at any given time.
> >>>>> Basically a map with pointers to simple structs and lists with
> pointers
> >>>>> to the same structs to allow for some simple access scenarios.
> >>>>>
> >>>>> Now I haven't profiled the app yet but even in a very pathologial
> case
> >>>>> it seems as though the GC would be able to keep up easily with such
> little
> >>>>> amount of memory being used. Granted this is a Standard 1x dyno but
> even so
> >>>>> once the machiine is stopped the GC should be able to complete it's
> work in
> >>>>> a very short time given the low used memory.
> >>>>>
> >>>>> Has anyone seen this as well? Could the Go metrics on Heroku simply
> >>>>> report erroneously? Perhaps a couple of orders of magnitide?
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> 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: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

I found https://github.com/davecheney/gcvis from +Dave Cheney
<d...@cheney.net> is it a good choice for inspecting the gc logs?

tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <dahankz...@gmail.com>:

> I have just added the gc tracing and it looks like this more or less all
> the time:
>
> gc 78 @253.095s 0%: 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms cpu,
> 11->12->4 MB, 12 MB goal, 8 P
> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock, 0.16+0.19/3.6/1.2+1.3 ms cpu,
> 9->9->4 MB, 10 MB goal, 8 P
> gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock, 0.17+0.27/4.8/0.006+18 ms cpu,
> 8->8->4 MB, 9 MB goal, 8 P
> gc 81 @253.138s 0%: 0.019+2.3+0.10 ms clock, 0.15+0.73/3.9/3.1+0.81 ms
> cpu, 9->9->5 MB, 10 MB goal, 8 P
>
> Heroku already reports a SW of 343 ms but I can't find it by manual
> inspection. I will download the logs later today and try to generate
> realistic load.
> What is the overhead of running like this, aside from the obvious extra
> logging?
> Are there any automatic tools to analyze these logs?
>
> lör 2 dec. 2017 kl 22:36 skrev Henrik Johansson <dahankz...@gmail.com>:
>
>> I am sorry, I was unclear. The app uses very little ram but the
>> provisioned available memory is 512 MB.
>>
>> I will try to experiment with GC toggles as you suggest and report back.
>>
>> Thx!
>>
>> On Sat, Dec 2, 2017, 22:18 rlh via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Hard telling what it going on. 35MB, even for 1 CPU, seems very small.
>>> Most modern system provision more than 1GB per HW thread though I've seen
>>> some provision as little as 512MB. GOGC (SetGCPercent) can be adjust so
>>> that the application uses more of the available RAM. Running with
>>> GODEBUG=gctrace=1 will give you a sense of the GC's view of the application.
>>>
>>> In any case these kinds of numbers, running on a real systems, and
>>> duplicatable on tip are worth filing an issue.
>>>
>>> On Saturday, December 2, 2017 at 3:02:30 AM UTC-5, Henrik Johansson
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am befuddled by GC SW times on several seconds (seen 20s once) in the
>>>> metrics page for our app. There are several things that are strange but
>>>> perhaps I am misreading it. The same metrics page reports Max Total 35 MB
>>>> out of which 1 MB s swap the rest RSS. The response times on the service is
>>>> has 99% ~400 ms which is not good but 95% is ~120 ms usually.
>>>> The app reloads an in memory cache as needed using atomic,Value as a
>>>> holder and the size is no more than a few thousand at any given time.
>>>> Basically a map with pointers to simple structs and lists with pointers
>>>> to the same structs to allow for some simple access scenarios.
>>>>
>>>> Now I haven't profiled the app yet but even in a very pathologial case
>>>> it seems as though the GC would be able to keep up easily with such little
>>>> amount of memory being used. Granted this is a Standard 1x dyno but even so
>>>> once the machiine is stopped the GC should be able to complete it's work in
>>>> a very short time given the low used memory.
>>>>
>>>> Has anyone seen this as well? Could the Go metrics on Heroku simply
>>>> report erroneously? Perhaps a couple of orders of magnitide?
>>>>
>>>> Cheers,
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> 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: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

I have just added the gc tracing and it looks like this more or less all
the time:

gc 78 @253.095s 0%: 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms cpu,
11->12->4 MB, 12 MB goal, 8 P
gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock, 0.16+0.19/3.6/1.2+1.3 ms cpu,
9->9->4 MB, 10 MB goal, 8 P
gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock, 0.17+0.27/4.8/0.006+18 ms cpu,
8->8->4 MB, 9 MB goal, 8 P
gc 81 @253.138s 0%: 0.019+2.3+0.10 ms clock, 0.15+0.73/3.9/3.1+0.81 ms cpu,
9->9->5 MB, 10 MB goal, 8 P

Heroku already reports a SW of 343 ms but I can't find it by manual
inspection. I will download the logs later today and try to generate
realistic load.
What is the overhead of running like this, aside from the obvious extra
logging?
Are there any automatic tools to analyze these logs?

lör 2 dec. 2017 kl 22:36 skrev Henrik Johansson <dahankz...@gmail.com>:

> I am sorry, I was unclear. The app uses very little ram but the
> provisioned available memory is 512 MB.
>
> I will try to experiment with GC toggles as you suggest and report back.
>
> Thx!
>
> On Sat, Dec 2, 2017, 22:18 rlh via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Hard telling what it going on. 35MB, even for 1 CPU, seems very small.
>> Most modern system provision more than 1GB per HW thread though I've seen
>> some provision as little as 512MB. GOGC (SetGCPercent) can be adjust so
>> that the application uses more of the available RAM. Running with
>> GODEBUG=gctrace=1 will give you a sense of the GC's view of the application.
>>
>> In any case these kinds of numbers, running on a real systems, and
>> duplicatable on tip are worth filing an issue.
>>
>> On Saturday, December 2, 2017 at 3:02:30 AM UTC-5, Henrik Johansson wrote:
>>>
>>> Hi,
>>>
>>> I am befuddled by GC SW times on several seconds (seen 20s once) in the
>>> metrics page for our app. There are several things that are strange but
>>> perhaps I am misreading it. The same metrics page reports Max Total 35 MB
>>> out of which 1 MB s swap the rest RSS. The response times on the service is
>>> has 99% ~400 ms which is not good but 95% is ~120 ms usually.
>>> The app reloads an in memory cache as needed using atomic,Value as a
>>> holder and the size is no more than a few thousand at any given time.
>>> Basically a map with pointers to simple structs and lists with pointers
>>> to the same structs to allow for some simple access scenarios.
>>>
>>> Now I haven't profiled the app yet but even in a very pathologial case
>>> it seems as though the GC would be able to keep up easily with such little
>>> amount of memory being used. Granted this is a Standard 1x dyno but even so
>>> once the machiine is stopped the GC should be able to complete it's work in
>>> a very short time given the low used memory.
>>>
>>> Has anyone seen this as well? Could the Go metrics on Heroku simply
>>> report erroneously? Perhaps a couple of orders of magnitide?
>>>
>>> Cheers,
>>>
>>> --
>> You received this message because you are subscribed to the Google 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: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

I am sorry, I was unclear. The app uses very little ram but the provisioned
available memory is 512 MB.

I will try to experiment with GC toggles as you suggest and report back.

Thx!

On Sat, Dec 2, 2017, 22:18 rlh via golang-nuts <golang-nuts@googlegroups.com>
wrote:

> Hard telling what it going on. 35MB, even for 1 CPU, seems very small.
> Most modern system provision more than 1GB per HW thread though I've seen
> some provision as little as 512MB. GOGC (SetGCPercent) can be adjust so
> that the application uses more of the available RAM. Running with
> GODEBUG=gctrace=1 will give you a sense of the GC's view of the application.
>
> In any case these kinds of numbers, running on a real systems, and
> duplicatable on tip are worth filing an issue.
>
> On Saturday, December 2, 2017 at 3:02:30 AM UTC-5, Henrik Johansson wrote:
>>
>> Hi,
>>
>> I am befuddled by GC SW times on several seconds (seen 20s once) in the
>> metrics page for our app. There are several things that are strange but
>> perhaps I am misreading it. The same metrics page reports Max Total 35 MB
>> out of which 1 MB s swap the rest RSS. The response times on the service is
>> has 99% ~400 ms which is not good but 95% is ~120 ms usually.
>> The app reloads an in memory cache as needed using atomic,Value as a
>> holder and the size is no more than a few thousand at any given time.
>> Basically a map with pointers to simple structs and lists with pointers
>> to the same structs to allow for some simple access scenarios.
>>
>> Now I haven't profiled the app yet but even in a very pathologial case it
>> seems as though the GC would be able to keep up easily with such little
>> amount of memory being used. Granted this is a Standard 1x dyno but even so
>> once the machiine is stopped the GC should be able to complete it's work in
>> a very short time given the low used memory.
>>
>> Has anyone seen this as well? Could the Go metrics on Heroku simply
>> report erroneously? Perhaps a couple of orders of magnitide?
>>
>> Cheers,
>>
>> --
> You received this message because you are subscribed to the Google 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] aws lambda native support for go in a few weeks

[Henrik Johansson]

Now we have to rewrite all our apps to use Lambda :D

Joking aside, it is cool and good news!

lör 2 dec. 2017 kl 00:38 skrev JM :

> just announced this week at re:invent. also cloud 9 the new dev ide also
> supports go.
>
> In case anyone cares ^^^
>
> --
> You received this message because you are subscribed to the Google 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] GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

Hi,

I am befuddled by GC SW times on several seconds (seen 20s once) in the
metrics page for our app. There are several things that are strange but
perhaps I am misreading it. The same metrics page reports Max Total 35 MB
out of which 1 MB s swap the rest RSS. The response times on the service is
has 99% ~400 ms which is not good but 95% is ~120 ms usually.
The app reloads an in memory cache as needed using atomic,Value as a holder
and the size is no more than a few thousand at any given time.
Basically a map with pointers to simple structs and lists with pointers to
the same structs to allow for some simple access scenarios.

Now I haven't profiled the app yet but even in a very pathologial case it
seems as though the GC would be able to keep up easily with such little
amount of memory being used. Granted this is a Standard 1x dyno but even so
once the machiine is stopped the GC should be able to complete it's work in
a very short time given the low used memory.

Has anyone seen this as well? Could the Go metrics on Heroku simply report
erroneously? Perhaps a couple of orders of magnitide?

Cheers,

-- 
You received this message because you are subscribed to the Google 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] Problems with JSON Marshal/UnmarshalText aand maps

[Henrik Johansson]

Huh... I could have sworn that I tried it.

Thx!

On Tue, Nov 28, 2017, 5:59 PM roger peppe <rogpe...@gmail.com> wrote:

> On 28 November 2017 at 16:30, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > Ok, thanks for the clarification.
> >
> > Is there some way to reliably handle these situations?
> > I really like the idea of custom value types as keys.
>
> As I did in my play.golang.org link, and others have pointed out too,
> you can do it by implementing UnmarshalText on the pointer type, not
> the value type.
> https://play.golang.org/p/VQPBwnh4Jn
>
>   cheers,
> rog.
> >
> >
> > On Tue, Nov 28, 2017, 5:22 PM roger peppe <rogpe...@gmail.com> wrote:
> >>
> >> > What tripped me up aside from reusing the map in the example was that
> in
> >> > case of errors a value type will still be put in the with it's
> default value
> >> > which my or may not for me.
> >>
> >> The reason for that is that your UnmarshalText method was being called
> >> on a pointer to the zero value,
> >> but was a value method, so the value was copied (all value methods are
> >> implemented by pointer
> >> values too), then your method couldn't change the original value, so
> >> the JSON unmarshaler
> >> just saw the zero value unchanged.
> >>
> >> On 28 November 2017 at 16:10, Henrik Johansson <dahankz...@gmail.com>
> >> wrote:
> >> > The time example I have was just an example.
> >> > I have a trivial struct as key.
> >> >
> >> > What tripped me up aside from reusing the map in the example was that
> in
> >> > case of errors a value type will still be put in the with it's default
> >> > value
> >> > which my or may not for me. I avoided the whole thing by just using
> >> > strings
> >> > as the key. A bit less typed but not unmanageable.
> >> >
> >> > Thanks for clarifying everyone!
> >> >
> >> >
> >> > On Tue, Nov 28, 2017, 3:34 PM Marvin Renich <m...@renich.org> wrote:
> >> >>
> >> >> * Henrik Johansson <dahankz...@gmail.com> [171128 07:43]:
> >> >> > But wouldn't unmarshal just overwrite in case of more trivial keys?
> >> >> >
> >> >> > So pointer receivers on the marshaling methods is better.
> >> >> > I think I tried it but something else blew up.
> >> >>
> >> >> While MarshalText can use a value or pointer receiver, it makes no
> >> >> sense
> >> >> to use a value receiver with UnmarshalText.  The UnmarshalText method
> >> >> must be able to change the caller's copy of the variable that is to
> >> >> hold
> >> >> the unmarshalled data.
> >> >>
> >> >> As for time.Time, if you read its documentation, it says that it
> holds
> >> >> both a wall clock time and a monotonic time.  time.Now() returns a
> >> >> structure that has both values, but some operations (e.g. time.Parse
> >> >> and
> >> >> time.Time.UnmarshalJSON) return a time.Time that only has a wall
> clock
> >> >> time.  t.Round(0) is the canonical way to strip the monotonic time
> from
> >> >> a time.Time value t.
> >> >>
> >> >> So after t := time.Now(); t2 := t.Round(0), t and t2 represent the
> same
> >> >> wall clock time, but compare as different, because the t has both
> wall
> >> >> clock and monotonic times, whereas t2 only has wall clock time.
> >> >>
> >> >> So your map with key time.Now() has a key with both times.  When you
> >> >> marshal it, the marshalled value only has wall clock time.  When you
> >> >> unmarshal it back to the same map, the unmarshalled time is different
> >> >> (but represents the same wall clock time) from the existing map key,
> so
> >> >> it creates an additional map element with the new key.
> >> >>
> >> >> If you create your map with keys that only have wall clock times with
> >> >> UTC location, as in https://play.golang.org/p/BCB3TAZADB, the
> >> >> unmarshalled key will match the existing key and overwrite it.  If
> you
> >> >> remove either .UTC() or .Round(0) or both from that code, you will
> >> >> notice that the map keys are different, and you end up with two
> values
> >> >> in the map after unmarshalling.
> >> >>
> >> >> ...Marvin
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> >> >> 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] Problems with JSON Marshal/UnmarshalText aand maps

[Henrik Johansson]

Ok, thanks for the clarification.

Is there some way to reliably handle these situations?
I really like the idea of custom value types as keys.

On Tue, Nov 28, 2017, 5:22 PM roger peppe <rogpe...@gmail.com> wrote:

> > What tripped me up aside from reusing the map in the example was that in
> case of errors a value type will still be put in the with it's default
> value which my or may not for me.
>
> The reason for that is that your UnmarshalText method was being called
> on a pointer to the zero value,
> but was a value method, so the value was copied (all value methods are
> implemented by pointer
> values too), then your method couldn't change the original value, so
> the JSON unmarshaler
> just saw the zero value unchanged.
>
> On 28 November 2017 at 16:10, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > The time example I have was just an example.
> > I have a trivial struct as key.
> >
> > What tripped me up aside from reusing the map in the example was that in
> > case of errors a value type will still be put in the with it's default
> value
> > which my or may not for me. I avoided the whole thing by just using
> strings
> > as the key. A bit less typed but not unmanageable.
> >
> > Thanks for clarifying everyone!
> >
> >
> > On Tue, Nov 28, 2017, 3:34 PM Marvin Renich <m...@renich.org> wrote:
> >>
> >> * Henrik Johansson <dahankz...@gmail.com> [171128 07:43]:
> >> > But wouldn't unmarshal just overwrite in case of more trivial keys?
> >> >
> >> > So pointer receivers on the marshaling methods is better.
> >> > I think I tried it but something else blew up.
> >>
> >> While MarshalText can use a value or pointer receiver, it makes no sense
> >> to use a value receiver with UnmarshalText.  The UnmarshalText method
> >> must be able to change the caller's copy of the variable that is to hold
> >> the unmarshalled data.
> >>
> >> As for time.Time, if you read its documentation, it says that it holds
> >> both a wall clock time and a monotonic time.  time.Now() returns a
> >> structure that has both values, but some operations (e.g. time.Parse and
> >> time.Time.UnmarshalJSON) return a time.Time that only has a wall clock
> >> time.  t.Round(0) is the canonical way to strip the monotonic time from
> >> a time.Time value t.
> >>
> >> So after t := time.Now(); t2 := t.Round(0), t and t2 represent the same
> >> wall clock time, but compare as different, because the t has both wall
> >> clock and monotonic times, whereas t2 only has wall clock time.
> >>
> >> So your map with key time.Now() has a key with both times.  When you
> >> marshal it, the marshalled value only has wall clock time.  When you
> >> unmarshal it back to the same map, the unmarshalled time is different
> >> (but represents the same wall clock time) from the existing map key, so
> >> it creates an additional map element with the new key.
> >>
> >> If you create your map with keys that only have wall clock times with
> >> UTC location, as in https://play.golang.org/p/BCB3TAZADB, the
> >> unmarshalled key will match the existing key and overwrite it.  If you
> >> remove either .UTC() or .Round(0) or both from that code, you will
> >> notice that the map keys are different, and you end up with two values
> >> in the map after unmarshalling.
> >>
> >> ...Marvin
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> 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] Problems with JSON Marshal/UnmarshalText aand maps

[Henrik Johansson]

The time example I have was just an example.
I have a trivial struct as key.

What tripped me up aside from reusing the map in the example was that in
case of errors a value type will still be put in the with it's default
value which my or may not for me. I avoided the whole thing by just using
strings as the key. A bit less typed but not unmanageable.

Thanks for clarifying everyone!

On Tue, Nov 28, 2017, 3:34 PM Marvin Renich <m...@renich.org> wrote:

> * Henrik Johansson <dahankz...@gmail.com> [171128 07:43]:
> > But wouldn't unmarshal just overwrite in case of more trivial keys?
> >
> > So pointer receivers on the marshaling methods is better.
> > I think I tried it but something else blew up.
>
> While MarshalText can use a value or pointer receiver, it makes no sense
> to use a value receiver with UnmarshalText.  The UnmarshalText method
> must be able to change the caller's copy of the variable that is to hold
> the unmarshalled data.
>
> As for time.Time, if you read its documentation, it says that it holds
> both a wall clock time and a monotonic time.  time.Now() returns a
> structure that has both values, but some operations (e.g. time.Parse and
> time.Time.UnmarshalJSON) return a time.Time that only has a wall clock
> time.  t.Round(0) is the canonical way to strip the monotonic time from
> a time.Time value t.
>
> So after t := time.Now(); t2 := t.Round(0), t and t2 represent the same
> wall clock time, but compare as different, because the t has both wall
> clock and monotonic times, whereas t2 only has wall clock time.
>
> So your map with key time.Now() has a key with both times.  When you
> marshal it, the marshalled value only has wall clock time.  When you
> unmarshal it back to the same map, the unmarshalled time is different
> (but represents the same wall clock time) from the existing map key, so
> it creates an additional map element with the new key.
>
> If you create your map with keys that only have wall clock times with
> UTC location, as in https://play.golang.org/p/BCB3TAZADB, the
> unmarshalled key will match the existing key and overwrite it.  If you
> remove either .UTC() or .Round(0) or both from that code, you will
> notice that the map keys are different, and you end up with two values
> in the map after unmarshalling.
>
> ...Marvin
>
> --
> You received this message because you are subscribed to the Google 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] Problems with JSON Marshal/UnmarshalText aand maps

[Henrik Johansson]

But wouldn't unmarshal just overwrite in case of more trivial keys?

So pointer receivers on the marshaling methods is better.
I think I tried it but something else blew up.


tis 28 nov. 2017 kl 12:55 skrev roger peppe <rogpe...@gmail.com>:

> You're seeing that behaviour because you're unmarshaling into the same map
> you started with, and encoding/json doesn't zero existing maps before
> unmarshaling into them.
>
> You see two members in the map because time.Now returns a time with a
> monotonic time but an unmarshaled time doesn't contain a monotonic time.
>
> This works OK: https://play.golang.org/p/KJk4iR3D3D
>
> On 27 November 2017 at 10:53, Henrik Johansson <dahankz...@gmail.com>
> wrote:
> > It seems that time.Time as keys exhibit the same issue:
> > https://play.golang.org/p/-_H3ZD6YLG
> >
> > Is this really intended or a bug?
> >
> > mån 27 nov. 2017 kl 11:25 skrev Henrik Johansson <dahankz...@gmail.com>:
> >>
> >> There is a discussion here
> >>
> https://groups.google.com/forum/#!searchin/golang-dev/json$20map/golang-dev/5gSHNrJQpUI/vZGSGRmUrC0J
> >> and an issue here: https://github.com/golang/go/issues/12146
> >>
> >> At least the issue has an initial example with a value type key
> >>
> >> mån 27 nov. 2017 kl 11:21 skrev James <proglot...@gmail.com>:
> >>>
> >>> Think UnmarshalText needs to have a pointer receiver or you'll only be
> >>> modifying a copy of the struct
> >>>
> >>> On 27 November 2017 at 23:13, Henrik Johansson <dahankz...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> https://play.golang.org/p/bLiYSsKL_7
> >>>>
> >>>> I have perhaps missed something simple or misunderstood the contract
> for
> >>>> MarshalText/UnmarshalText but it seems to me that it should work it
> just
> >>>> doesn't... :)
> >>>>
> >>>> If I uncomment the return of the parse error "BOOM" then I just get a
> >>>> new "default" key with 3 underscores.
> >>>>
> >>>> Anyone knows what I missed?
> >>>>
> >>>> Thx,
> >>>> Henrik
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> 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] Problems with JSON Marshal/UnmarshalText aand maps

[Henrik Johansson]

It seems that time.Time as keys exhibit the same issue:
https://play.golang.org/p/-_H3ZD6YLG

Is this really intended or a bug?

mån 27 nov. 2017 kl 11:25 skrev Henrik Johansson <dahankz...@gmail.com>:

> There is a discussion here
> https://groups.google.com/forum/#!searchin/golang-dev/json$20map/golang-dev/5gSHNrJQpUI/vZGSGRmUrC0J
> and an issue here: https://github.com/golang/go/issues/12146
>
> At least the issue has an initial example with a value type key
>
> mån 27 nov. 2017 kl 11:21 skrev James <proglot...@gmail.com>:
>
>> Think UnmarshalText needs to have a pointer receiver or you'll only be
>> modifying a copy of the struct
>>
>> On 27 November 2017 at 23:13, Henrik Johansson <dahankz...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> https://play.golang.org/p/bLiYSsKL_7
>>>
>>> I have perhaps missed something simple or misunderstood the contract for
>>> MarshalText/UnmarshalText but it seems to me that it should work it just
>>> doesn't... :)
>>>
>>> If I uncomment the return of the parse error "BOOM" then I just get a
>>> new "default" key with 3 underscores.
>>>
>>> Anyone knows what I missed?
>>>
>>> Thx,
>>> Henrik
>>>
>> --
>>> You received this message because you are subscribed to the Google
>>> 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] Problems with JSON Marshal/UnmarshalText aand maps

[Henrik Johansson]

There is a discussion here
https://groups.google.com/forum/#!searchin/golang-dev/json$20map/golang-dev/5gSHNrJQpUI/vZGSGRmUrC0J
and an issue here: https://github.com/golang/go/issues/12146

At least the issue has an initial example with a value type key

mån 27 nov. 2017 kl 11:21 skrev James <proglot...@gmail.com>:

> Think UnmarshalText needs to have a pointer receiver or you'll only be
> modifying a copy of the struct
>
> On 27 November 2017 at 23:13, Henrik Johansson <dahankz...@gmail.com>
> wrote:
>
>> Hi,
>>
>> https://play.golang.org/p/bLiYSsKL_7
>>
>> I have perhaps missed something simple or misunderstood the contract for
>> MarshalText/UnmarshalText but it seems to me that it should work it just
>> doesn't... :)
>>
>> If I uncomment the return of the parse error "BOOM" then I just get a new
>> "default" key with 3 underscores.
>>
>> Anyone knows what I missed?
>>
>> Thx,
>> Henrik
>>
> --
>> You received this message because you are subscribed to the Google 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] Problems with JSON Marshal/UnmarshalText aand maps

[Henrik Johansson]

Hi,

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

I have perhaps missed something simple or misunderstood the contract for
MarshalText/UnmarshalText but it seems to me that it should work it just
doesn't... :)

If I uncomment the return of the parse error "BOOM" then I just get a new
"default" key with 3 underscores.

Anyone knows what I missed?

Thx,
Henrik

-- 
You received this message because you are subscribed to the Google 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: Would someone care to compare Firefox Quantum Rust concurrency features to Go....

[Henrik Johansson]

Ifaik rusts safety is compiler magic. Nothing special runtime you just
can't share stuff in dangerous ways. Syntax is horrible compared to Go but
who knows sometimes it can maybe be worth it.

On Sat, 25 Nov 2017, 05:10 ,  wrote:

>
>
> On Thursday, November 23, 2017 at 9:15:27 AM UTC-7, Haddock wrote:
>>
>> Concurrency in Rust and Go are completely different things. In Rust a
>> thread has its own memory space and hence a thread cannot reference data by
>> reference of some other thread. The rational behind that is security. Also,
>> a thread in Rust is not lightweight, but a full-blown OS thread. So there
>> is no CSP in Rust as in Go and therefore there is little to compare between
>> Rust and Go concerning concurrency. AFAIK, there is some crate in Rust that
>> adds some minimal support for coroutines, but I don't think its used in
>> Servo.
>>
>
> I've read about both Rust and Go, but I'm not very familiar with either. I
> am more interested in Go because it has lightweight threads, which seem to
> take better advantage of a multi-core system.
> I don't know what CSP or "crate"  mean.
>
> In my processor I support a Forth that has "quotations." These are
> anonymous nested functions defined inside of a parent function.
> The quotation's xt (execution token) can be passed as a parameter to a HOF
> (higher-order function) that can EXECUTE it (typically inside of a loop).
> Typically the HOF will traverse a data-structure and execute the quotation
> for every node in the data-structure.
> The cool thing is that the quotation has access to the parent function's
> local variables --- it can read or write to them --- this is despite the
> fact that the HOF has local variables of its own.
>
> Do either Rust or Go have anything comparable to my quotations?
> Note that my quotations are not like Scheme closures --- they can only be
> executed so long as the parent function is in scope ---
> in Scheme the parent function can exit and the closure is still valid,
> because the local-frame is in the heap and doesn't get GC'd until all the
> closures have been killed.
> I don't have GC in my system --- I have a simpler system that supports
> general-purpose data-structures --- my processor is intended to be a
> micro-controller.
>
> I have something called rquotations that are almost like quotations, with
> the minor limitation that the xt can't be determined at compile-time (so
> they can't be used in my  These are not ANS-Forth, but they have been implemented in both VFX and
> SwiftForth, and could easily be implemented in any ANS-Forth system (given
> some carnal knowledge).
>
> Has Go been implemented for use on any micro-controller? Or is it purely a
> desktop-computer language?
> My multi-core Forth processor will obviously be programmed in Forth. It
> may be possible for a language such as Go to generate Forth code that runs
> on my processor though.
> Each core has its own zero-page that includes the data-stack and
> return-stack. The rest of the memory is shared.
>
> --
> You received this message because you are subscribed to the Google 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: concurrency programing about go

[Henrik Johansson]

Indeed this is what I do but I learned the hard way and often it comes up
as "safe" in the mailing list to not do so but while true from a memory
model perspective it is, I would say, wrong to do so.

mån 6 nov. 2017 kl 10:39 skrev Christoph Berger <
christoph.g.ber...@gmail.com>:

> Always call Add() before spawning the corresponding goroutine(s). And
> always call Add() in the same goroutine that also calls Wait(). This way
> you have no race condition between Add(), Done(), and Wait().
>
>
> On Saturday, November 4, 2017 at 10:46:21 AM UTC+1, Henrik Johansson wrote:
>
>> I find continuously adding and calling done on a waitgroup a bit odd. The
>> waiting goroutine can continue as soon as the count is zero so there is  a
>> race between adds and dones.
>>
>> On Sat, 4 Nov 2017, 10:01 , <28911...@gmail.com> wrote:
>>
> Thank you very much.Sorry I still have some question:what's the function
>>> of wg? what does the sentense "wg.Add(2) " mean?? I found that if I change
>>> 2 into 1,the result is differnet.
>>>
>>> 在 2017年11月3日星期五 UTC+8上午4:45:47，snmed写道：
>>>
>>>> Hi
>>>>
>>>> Here is the code:
>>>>
>>>> Version 1:
>>>> package main
>>>>
>>>> import (
>>>> "fmt"
>>>> "sync"
>>>> )
>>>>
>>>> var a string
>>>> var once sync.Once
>>>>
>>>> func setup() {
>>>> a = "hello,world\n"
>>>> }
>>>> func doprint() {
>>>> once.Do(setup)
>>>> fmt.Print(a)
>>>> }
>>>> func twoprint() <-chan struct{} {
>>>> var wg sync.WaitGroup
>>>> wg.Add(2)
>>>> ch := make(chan struct{})
>>>>
>>>> go func() {
>>>> doprint()
>>>> wg.Done()
>>>> }()
>>>> go func() {
>>>> doprint()
>>>> wg.Done()
>>>> }()
>>>>
>>>> go func() {
>>>> wg.Wait()
>>>> close(ch)
>>>> }()
>>>>
>>>> return ch
>>>> }
>>>>
>>>> func main() {
>>>> ch := twoprint()
>>>> <-ch
>>>> }
>>>>
>>>>
>>>> Version 2:
>>>> package main
>>>>
>>>> import (
>>>> "fmt"
>>>> "sync"
>>>> )
>>>>
>>>> var a string
>>>> var once sync.Once
>>>>
>>>> func setup() {
>>>> a = "hello,world\n"
>>>> }
>>>> func doprint() {
>>>> once.Do(setup)
>>>> fmt.Print(a)
>>>> }
>>>> func twoprint() {
>>>> var wg sync.WaitGroup
>>>> wg.Add(2)
>>>>
>>>> go func() {
>>>> doprint()
>>>> wg.Done()
>>>> }()
>>>> go func() {
>>>> doprint()
>>>> wg.Done()
>>>> }()
>>>>
>>>> wg.Wait()
>>>> }
>>>>
>>>> func main() {
>>>> twoprint()
>>>> }
>>>>
>>>>
>>>> Cheers snmed
>>>>
>>>>
>>>> Am Donnerstag, 2. November 2017 10:37:15 UTC+1 schrieb
>>>> 28911...@gmail.com:
>>>>>
>>>>> Sorry,I try my best to open the website but it can't work.Can you
>>>>> write it ??Thank you so much.
>>>>>
>>>>> 在 2017年10月30日星期一 UTC+8下午4:29:44，snmed写道：
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> There are several ways to solve it, here are two of them:
>>>>>>
>>>>>> https://play.golang.org/p/wJwkI7HQwv
>>>>>> https://play.golang.org/p/nasUcgBeG4
>>>>>>
>>>>>> I prefer the first one, because so I can decide if i want to wait for
>>>>>> the end of twoprint or not.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Am Montag, 30. Oktober 2017 06:43:45 UTC+1 schrieb 28911...@gmail.com
>>>>>> :
>>>>>>>
>>>>>>> Yes, you're right.So how to solve it??
>>>>>>>
>>>>>>> 在 2017年10月30日星期一 UTC+8下午12:37:49，Dave Cheney写道：
>>>>>>>>
>>>>>>>> Hello. I’m guessing that your tried calling twoprint(), but you’ve
>>>>>>>> probably found that nothing is printed to the screen before your 
>>>>>>>> program
>>>>>>>> exits.
>>>>>>>>
>>>>>>>> Is that correct?
>>>>>>>
>>>>>>> --
>>> You received this message because you are subscribed 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: concurrency programing about go

[Henrik Johansson]

I find continuously adding and calling done on a waitgroup a bit odd. The
waiting goroutine can continue as soon as the count is zero so there is  a
race between adds and dones.

On Sat, 4 Nov 2017, 10:01 , <2891132l...@gmail.com> wrote:

> Thank you very much.Sorry I still have some question:what's the function
> of wg? what does the sentense "wg.Add(2) " mean?? I found that if I change
> 2 into 1,the result is differnet.
>
> 在 2017年11月3日星期五 UTC+8上午4:45:47，snmed写道：
>
>> Hi
>>
>> Here is the code:
>>
>> Version 1:
>> package main
>>
>> import (
>> "fmt"
>> "sync"
>> )
>>
>> var a string
>> var once sync.Once
>>
>> func setup() {
>> a = "hello,world\n"
>> }
>> func doprint() {
>> once.Do(setup)
>> fmt.Print(a)
>> }
>> func twoprint() <-chan struct{} {
>> var wg sync.WaitGroup
>> wg.Add(2)
>> ch := make(chan struct{})
>>
>> go func() {
>> doprint()
>> wg.Done()
>> }()
>> go func() {
>> doprint()
>> wg.Done()
>> }()
>>
>> go func() {
>> wg.Wait()
>> close(ch)
>> }()
>>
>> return ch
>> }
>>
>> func main() {
>> ch := twoprint()
>> <-ch
>> }
>>
>>
>> Version 2:
>> package main
>>
>> import (
>> "fmt"
>> "sync"
>> )
>>
>> var a string
>> var once sync.Once
>>
>> func setup() {
>> a = "hello,world\n"
>> }
>> func doprint() {
>> once.Do(setup)
>> fmt.Print(a)
>> }
>> func twoprint() {
>> var wg sync.WaitGroup
>> wg.Add(2)
>>
>> go func() {
>> doprint()
>> wg.Done()
>> }()
>> go func() {
>> doprint()
>> wg.Done()
>> }()
>>
>> wg.Wait()
>> }
>>
>> func main() {
>> twoprint()
>> }
>>
>>
>> Cheers snmed
>>
>>
>> Am Donnerstag, 2. November 2017 10:37:15 UTC+1 schrieb 28911...@gmail.com
>> :
>>>
>>> Sorry,I try my best to open the website but it can't work.Can you write
>>> it ??Thank you so much.
>>>
>>> 在 2017年10月30日星期一 UTC+8下午4:29:44，snmed写道：

 Hi

 There are several ways to solve it, here are two of them:

 https://play.golang.org/p/wJwkI7HQwv
 https://play.golang.org/p/nasUcgBeG4

 I prefer the first one, because so I can decide if i want to wait for
 the end of twoprint or not.

 Cheers

 Am Montag, 30. Oktober 2017 06:43:45 UTC+1 schrieb 28911...@gmail.com:
>
> Yes, you're right.So how to solve it??
>
> 在 2017年10月30日星期一 UTC+8下午12:37:49，Dave Cheney写道：
>>
>> Hello. I’m guessing that your tried calling twoprint(), but you’ve
>> probably found that nothing is printed to the screen before your program
>> exits.
>>
>> Is that correct?
>
> --
> You received this message because you are subscribed to the Google 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] Handling dynamic and unknown number of wait groups?

[Henrik Johansson]

And technically they are not tracking goroutines but done things. Each
goroutine could each finish 10 things.

On Thu, 2 Nov 2017, 17:01 Andy Balholm,  wrote:

> You can add goroutines to a WaitGroup as you create them. There is nothing
> that keeps you from calling Add more than once.
>
> Andy
>
>
> On Nov 1, 2017, at 11:10 PM, kanth...@gmail.com wrote:
>
> I am new to Go and I had read numerous times in various articles that one
> can technically create any number of Go routines and the runtime takes care
> of them mapping to kernel threads. If so, why does waitGroup designed in a
> way such that one has to specify how many go routines one need to create
> ahead of time ? why can't waitGroup be more dynamic such that I can add a
> Goroutine to waitgroup once I create it ? To put the question in another
> way why are people even thinking about pool of go routines in the first
> place given that goroutines are user level threads? If someone talks about
> pool of goroutines I feel like I am back to C++ or any other language that
> creates pool of kernel threads. Does Go runtimes doesn't keep its promise?
> Again, I am new so please enlighten me.
>
> On Wednesday, June 29, 2016 at 3:35:31 PM UTC-7, Inspectre Gadget wrote:
>>
>> Hey everyone,
>>
>> Here’s my issue, I will try to keep this short and concise:
>>
>> I have written a program that will accept a URL, spider that URL’s domain
>> and scheme (http/https), and return back all input fields found throughout
>> to the console. The purpose is largely for web application security
>> testing, as input fields are the most common vulnerability entry points
>> (sinks), and this program automates that part of the reconnaissance phase.
>>
>> Here is the problematic code:
>> https://github.com/insp3ctre/input-field-finder/blob/ce7983bd336ad59b2e2b613868e49dfb44110d09/main.go
>>
>> The issue lies in the last for loop in the main() function. If you were
>> to run this program, it would check the queue and workers so frequently
>> that it is bound to find a point where there are both no workers working,
>> and no URLs in the queue (as proved by the console output statements before
>> it exits). Nevermind that the problem is exacerbated by network latency.
>> The number of URLs actually checked varies on every run, which causes some
>> serious inconsistencies, and prevents the program from being at all
>> reliable.
>>
>> The issue was fixed here:
>> https://github.com/insp3ctre/input-field-finder/blob/f0032bb550ced0b323e63be9c4f40d644257abcd/main.go
>>
>> I fixed it by removing all concurrency from network requests, leaving it
>> only in the internal HTML processing functions.
>>
>> So, the question is- how does one run efficient concurrent code when the
>> number of wait groups is dynamic, and unknown at program initialization?
>>
>> I have tried:
>>
>>- Using “worker pools”, which consist of channels of workers. The for
>>loop checks the length of the URL queue and the number of workers
>>available. If the URL queue is empty and all the workers are available,
>>then it exits the loop.
>>- Dynamically adding wait groups (wg.Add(1)) every time I pull a URL
>>from the URL queue. *I can’t set the wait group numbers before the
>>loop, because I can never know how many URLs are going to be checked.*
>>
>>
>> So I have tried using both channels and wait groups to check alongside
>> the URL queue length to determine whether more concurrent network requests
>> are needed. In both cases, the for loop checks the values so fast that it
>> eventually stumbles upon a non-satisfied loop condition, and exits. This
>> usually results in either the program hanging as it waits for wait groups
>> to exit that never do, or it simply exits prematurely, as more URLs are
>> added to the queue after the fact.
>>
>> I would really like to know if there is a way to actually do this well in
>> Go.
>>
>> Cheers,
>>
>> Inspectre
>>
>
> --
> You received this message because you are subscribed to the Google 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] mutual exclusion algorithm of Dijkstra - strange behaviour

[Henrik Johansson]

I think it's the non-preemptive scheduler that hits you.
Afaik it is a known behavior that I am not sure how to fix.
I did not at all look at the solution itself.

mån 30 okt. 2017 kl 18:29 skrev :

> Dear Go-community,
>
> I noticed a very strange effect by translating the
> mutual exclusion algorithm of E. W. Dijkstra to Go.
> Reference:
>   Cooperating Sequential Processes. Technical Report EWD-123,
>   Technological University Eindhoven (1965)
>   http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF)
>
> Inserting or omitting code lines A and B resp.
> changes the behaviour of this program very severely:
>
> With line A and without line B:
>   mutual exclusion is not guaranteed,
> with line B and without line A:
>   lock does not terminate and
> with both lines:
>   the program works as it should.
>
> --- 8< 
> package main
>
> import (
>   "math/rand"
>   "time"
> )
>
> const N = 10 // number of goroutines involved
>
> var (
>   turn int
>   b, c = make([]int, N+1), make([]int, N+1)
>   n= uint(0)
>   inCS = make([]bool, N+1)
>   s= make([]string, N+1)
>   done = make(chan int)
> )
>
> func chk(i int) {
>   for j := 1; j <= N; j++ {
> if j != i && inCS[j] {
>   panic("oops")
> }
>   }
> }
>
> func lock(i int) {
>   b[i] = 0
> L:
>   if turn != i {
> c[i] = 1
> if b[turn] == 1 {
>   turn = i
>   goto L
> }
>   }
>   time.Sleep(1) // A
>   c[i] = 0
>   time.Sleep(1) // B
>   for j := 1; j <= N; j++ {
> if j != i && c[j] == 0 {
>   goto L
> }
>   }
>   inCS[i] = true
>   chk(i)
> }
>
> func unlock(i int) {
>   inCS[i] = false
>   c[i], b[i] = 1, 1
>   //  turn = 0 // does not matter
> }
>
> func v() {
>   time.Sleep(time.Duration(1e7 + rand.Int63n(1e7)))
> }
>
> func count(i int) {
>   for k := 0; k < 100; k++ {
> lock(i)
> accu := n
> v()
> accu++
> v()
> n = accu
> v()
> println(s[i], n)
> unlock(i)
> v()
>   }
>   done <- 0
> }
>
> func main() {
>   s[1] = ""
>   for i := 2; i <= N; i++ {
> s[i] = s[i-1] + "   "
>   }
>   for i := 1; i <= N; i++ {
> go count(i)
>   }
>   for i := 1; i <= N; i++ {
> <-done
>   }
> }
> --- >8 
>
> The cause for the "freaking out" of the program without
> those compulsory breaks (of only 1 ns) is absolutely unclear.
>
> Any sort of help is welcome!
>
> Kind regards to everybody,
>
> Christian Maurer
>
> --
> You received this message because you are subscribed to the Google 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: slice of pointer of struct vs slice of struct

[Henrik Johansson]

No, you are right but then I have made an explicit decision that state is
important and mutable so hopefully I would take that into consideration
when exposing the data.

lör 21 okt. 2017 kl 13:00 skrev Juliusz Chroboczek :

> > I have started to use non pointer slices much more as of late.
> > Every time I bother measuring it is always faster and it is better for
> the
> > GC (usually, caveats apply).
>
> So do I.  I was just pointing out a caveat that tripped me a couple times.
>
> > It also, perhaps naively, feels safer... :)
>
> Not if your structs contain a Mutex.
>
> -- Juliusz
>
> --
> You received this message because you are subscribed to the Google 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: slice of pointer of struct vs slice of struct

[Henrik Johansson]

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

I have started to use non pointer slices much more as of late.
Every time I bother measuring it is always faster and it is better for the
GC (usually, caveats apply).

It also, perhaps naively, feels safer... :)

fre 20 okt. 2017 kl 13:41 skrev Juliusz Chroboczek :

> >> What size of T affects is appending/inserting/deleting items to/from
> >> the slice. If one passes around a value of type []T, those operations
> >> are probably performed on the value.
>
> > On the flip side, []*T will be less cache/TLB/GC friendly than
> > []T, unless T is much larger than a ptr.
>
> On the edge side, []T cannot be easily ranged over in a mutable way:
> https://play.golang.org/p/6kpQWkLQEW
>
> -- Juliusz
>
> --
> You received this message because you are subscribed to the Google 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] Rewriting a realtime game server from Node.js to Golang

[Henrik Johansson]

No not at all. If you can write a game engine in any language you should be
fine just try to avoid too big design decisions too early so that once you
get a better grasp of Go you can more easily refactor.

mån 2 okt. 2017 kl 06:13 skrev Aaron :

> Hi I am in a process of rewriting a realtime game server from Node.js to
> Golang. It's two to three thousand lines of code in Node.js. But I have no
> previous Golang experience so it's hard to measure the workload. Do you
> think it is better for me to do some other bigger projects before I start
> rewriting my game server?
>
> --
> You received this message because you are subscribed to the Google 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: Proposal: Just Use GitHub

[Henrik Johansson]

 I am sorry but this type of straw man is not what Nate and others are
arguing for.
Never has anyone suggested we sacrifice quality for quantity but rather
that more better than less to turn the old adage around.

If code review can be done efficiently enough and by enough people then
more contributors is better.
I think a move like this would initially hurt the process but over time
improve it since more contributors would also lead to more reviewers.

My 2¢

sön 24 sep. 2017 kl 09:01 skrev Nigel Vickers :

>
>
> On Thursday, 21 September 2017 04:27:19 UTC+2, Nate Finch wrote:
>>
>> https://github.com/golang/go/issues/21956
>>
>> Wherein I suggest that not using GitHub for PRs and Reviews for the Go
>> Project itself is hurting the language and the community.
>>
>
> I have been lurking on this discussion until now. I do not "like" the
> nature or tone that this discussion has taken.  I am not a contributor to
> Go but have experience with a large Open Source Project. I use Go daily.
> All Communities have problems attracting contributors, but the problem is
> not just "Quantity" it is also "Quality". PRs cannot be just accepted; they
> have to be "Reviewed". I think the "worst" case I have encountered involved
> 6 lines of PHP code that "ping ponged" 26 times before a "programmer with a
> bad case of agenda" accepted that his code wasn't doing what he thought.
> Reviewers' working in such environments are rare and their feelings on the
> matter must be respected. GitHubs' review procedure does not have the depth
> or history that is necessary.
>
> Suggestions that the "Leaders of the Project" are following some hidden
> "Google Agenda" is unacceptable. You should be taking the state of Githubs'
> review to GitHub and not proposing to "Hamstring" the Go reviewers.
>
> imho.
>
>
> --
> You received this message because you are subscribed to the Google 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] Magefiles - a makefile replacement using go

[Henrik Johansson]

I just have a case where I was wondering if a Makefile could be the answer.
Ill try mage instead and see what it can do!

lör 23 sep. 2017 kl 07:11 skrev snmed :

> Hi Nate
>
> Awesome, i never liked make files and fortunately i could use npm scripts
> to build front and backend. I'm glad to see an alternative to make files in
> go, i will give it a try.
>
> Cheers Sandro
>
> --
> You received this message because you are subscribed to the Google 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] Do you check in vendor packages?

[Henrik Johansson]

I always check in. It is super nice to not have to download separately and
have one transitive dep destroy everything when you need it the least.

On Fri, 15 Sep 2017, 02:37 Kevin Malachowski  wrote:

> I generally vote for checking in, or at least ensuring that /something/
> has an in-house copy of all dependencies. The worst thing that can happen
> is someone deleting their repository and having your project being super
> broken.
>
> (See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)
>
> --
> You received this message because you are subscribed to the Google 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: Do you guys use ORMs when working with SQL?

[Henrik Johansson]

The switching of databases can happen but I have always solved it at a
higher "service" level.
What ORM's help you with is quickly getting started and it can in some
cases help you with type safety. In the (not so) long run only the second
matter and personally I wish there was something like Slick
http://slick.lightbend.com/ for Go that would help when a project grows and
lots of people touch the queries over time.

sön 10 sep. 2017 kl 23:16 skrev M. Shulhan :

>

-- 
You received this message because you are subscribed to the Google 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: Choosing a framework

[Henrik Johansson]

Maybe it is better nowadays but at least last time I tried a bigger
framework the first thing that happened was I had to either change logger
or wrestle with how the framework did it's logging.
I would from experience in both Go and other languages (mostly Java, Spring
is not your friend) very much recommend choosing a smaller set of libraries
that each do a limited thing. It will hurt more than it is worth in the
long run.


mån 11 sep. 2017 kl 06:50 skrev Henry :

> Actually, there is nothing in Go that prevents you from using any kind of
> frameworks. You are free to use whatever you wish.
>
> Go provides a more complete standard library for web development than many
> other programming languages. While in other languages you have to rely on
> frameworks, in Go, building your own framework isn't that difficult.
>
> That being said, just choose whatever suits your needs.
>
> --
> You received this message because you are subscribed to the Google 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] error handling needs syntactical sugar

[Henrik Johansson]

I think Rob is really on to something here and I have seen it evolve in my
own programming.
I tend to make simple things "flatter" and model things around cores that
don't error out and just at the boundaries evaluate and possibly produce an
error.
Is that "monadic"? Anyway it gets easier if you try but of course it is
hard to extrapolate to the general case.

tis 5 sep. 2017 kl 16:01 skrev Dorival Pedroso :

> Wojciech, you're right: It'll effectively work as a "catch" (or
> "recover"); e.g. something like:
>
> defer func() {
> if err := recover(); err != nil {
> fmt.Printf("ERROR: %v\n", err)
> }
> }()
>
> The only difference is that we wouldn't have to "throw" or "panic". The
> compiler would just "watch" the "behaviour" of the error variable.
>
> But, hey, I think we're all very happy with the options we have to handle
> errors in Go: we have the "error" keyword AND panic/recover! That's great!
>
> Also, I think we're just wondering whether a "syntactical sugar" is worth
> in Go or not (speaking for myself, of course).
>
> Best wishes.
> Dorival
>
> On Tuesday, September 5, 2017 at 11:07:12 PM UTC+10, ohir wrote:
>
>> On Tue, 5 Sep 2017 00:20:09 -0700 (PDT)
>>
> Dorival Pedroso  wrote:
>>
>> > I realised I've written 569 "if err != nil":
>> > And I've written 231 error messages
>> > And I have a feeling that I've done only 20% of the error messages...
>>
>> Factor 2,46 so far.
>>
>> It directly *proves* that any 'watch' construct would get us soon to
>> 'spooky
>> action at distance' at massive scale. What is now written just after call
>> would get a trip to some distant watch block and be 'cased' there.
>>
>> So why call it 'watch' at all? It would be simply a 'catch' :)
>>
>> BAD.
>>
>> > See the messages
>> > here: https://gist.github.com/cpmech/d2e36dcbe277cd72605f3732d79c798b
>>
>>
>> --
>> Wojciech S. Czarnecki
>>  << ^oo^ >> OHIR-RIPE
>>
> --
> You received this message because you are subscribed to the Google 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] sync.Map for caching

[Henrik Johansson]

If you absolutely must make sure you ever create 2 instances of any value
in the map then I guess you have to lock.
Otherwise you can maybe use map.LoadOrStore?

fre 1 sep. 2017 kl 00:18 skrev bep :

> sync.Map in Go 1.9 is a little low on examples/doc in the wild, so I
> thought I should ask here.
>
> The new type is promoted as a replacement for  RWMutex in mostly read use
> cases with stable keys. I assume that a typical in memory cache would fit
> that description.
>
> With RWMutex, if the cost of creating the cache item is high, I would
> maybe do something ala:
>
> mu.RLock()
> // Check cache
> mu.RUnclock()
>
> // Return if found
>
> // If Not found:
> mu.Lock()
> defer mu.Unlock()
> // Double check cache, return if found
> // Create item and put in cache
>
>
>
>
> I don't see how the above can be written with a sync.Map without adding a
> mutex.
>
> bep
>
> --
> You received this message because you are subscribed to the Google 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] Running Go binary on a 56 core VM

[Henrik Johansson]

Try it out! It would be great if the scheduler and garbage collector could
be so good as to making such tricks unnecessary.

On Thu, 31 Aug 2017, 15:59  wrote:

> Hi Guys,
>
> So, we wrote a Go service which does some heavy network IO over ZMQ (using
> cgo calls).
>
> Now, we have to put this service on a VM in private cloud which has 56
> cores and 256GB of physical memory.
>
> I am guessing it is mostly a dual core NUMA Intel Xeon machine with Xen
> installed on it.
>
> We want to horizontally scale the application by launching 4 instances of
> this service in this VM.
>
> We have tested the code for 30K+ QPS on a 16 core EC2 AMI.
>
> There are two ways we can do it.
>
> 1. Run 4 instances of the application as it is without changing any
> defaults except configuration files and output data folders.
>
> 2. Run 4 instances of the application after modifying GOMAXPROCS.
> - GOMAXPROCS=16 ./run-my-unoptimized-app
>
> Which of these 2 scenarios would benefits us more in terms of performance.
>
> Does it makes sense to run all with default GOMAXPROCS value, which would
> be 56 for all the 4 instances?
>
> Or it would be wise to follow option 2 with possibly pinning each to a
> range of 16 cores using taskset.
>
> Would pinning help in second scenario?
>
> 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.