Re: [go-nuts] Line wrapping and the lack of some convention

[Sotirios Mantziaris]

Thanks for the link, this clears things out a bit.

On Fri, 6 Sep 2019 at 02:21, Ian Lance Taylor  wrote:

> On Thu, Sep 5, 2019 at 10:59 AM Sotirios Mantziaris
>  wrote:
> >
> > I would liked that gofmt would handle this one also in order to avoid
> battles about what is the correct line wrapping in go.
> >
> > In Effective Go there is a section, with smaller fonts than the usual
> document that states:
> >
> > Line lengthGo has no line length limit. Don't worry about overflowing a
> punched card. If a line feels too long, wrap it and indent with an extra
> tab.
> >
> > The above line leaves a lot of room for interpretation:
> >
> > Assume you have something lengthy, which is also left for
> interpretation, you should wrap and ident with an extra tab:
> >
> > Now I have the following outcomes:
> >
> > shinyThing := New(argument1 string, argument2 string, argument3 string,
> >   argument4 string, argument5 string)
> >
> >
> > you have
> >
> > shinyThing  := New(
> >   argument1 string,
> >   argument2 string,
> >   argument3 string,
> >   argument4 string,
> >   argument5 string
> > )
> >
> > and there are possibly 100 more variations out there.
> >
> > I personally prefer the first one because I use as much horizontal space
> as I can (i have a limit for 120 chars per line) and I use as little as
> possible vertical space in order to not need to scroll. I optimize for
> having as much as possible in one screen.
> >
> > Does anybody have a convention that is generally accepted for this?
>
> There is some discussion at
> https://golang.org/wiki/CodeReviewComments#line-length .
>
> > Would this make sense to be part of gofmt?
>
> I don't think so, because good line breaks require semantic knowledge
> that gofmt doesn't have.
>
> Ian
>


-- 
Regards,

S. Mantziaris

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

[go-nuts] Line wrapping and the lack of some convention

[Sotirios Mantziaris]

Hi,

I would liked that gofmt would handle this one also in order to avoid 
battles about what is the correct line wrapping in go.

In Effective Go there is a section, with smaller fonts than the usual 
document that states:

Line lengthGo has no line length limit. Don't worry about overflowing a 
punched card. If a line feels too long, wrap it and indent with an extra 
tab.

The above line leaves a lot of room for interpretation:

Assume you have something lengthy, which is also left for interpretation, 
you should wrap and ident with an extra tab:

Now I have the following outcomes:

shinyThing := New(argument1 string, argument2 string, argument3 string,
  argument4 string, argument5 string)


you have

shinyThing  := New(
  argument1 string, 
  argument2 string, 
  argument3 string,
  argument4 string, 
  argument5 string
)

and there are possibly 100 more variations out there.

I personally prefer the first one because I use as much horizontal space as 
I can (i have a limit for 120 chars per line) and I use as little as 
possible vertical space in order to not need to scroll. I optimize for 
having as much as possible in one screen.

Does anybody have a convention that is generally accepted for this?
Would this make sense to be part of gofmt?

-- 
You received this message because you are subscribed to the Google 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/11db50dc-d8e2-4a75-b9a2-bf00ae7f9a89%40googlegroups.com.

[go-nuts] ANN: Harvester, an easy to use dynamic configuration package

[Sotirios Mantziaris]

Hi,

i would like to announce a new package that can be used to dynamically 
reconfigure your application without having the need to restart it.

https://github.com/beatlabs/harvester

Feedback is highly appreciated.

-- 
You received this message because you are subscribed to the Google 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/565574f7-34e4-4b85-8a8b-60bb3564785a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] ANN: Harvester, a easy to sue dynamic configuration package

[Sotirios Mantziaris]

Hi,

i would like to announce a new package that can be used to dynamically 
reconfigure your application without having the need to restart it.

Features:

- Handling static config like seed values, env vars
- Handling dynamic changing values with Consul support
- Extensible via interfaces

https://github.com/beatlabs/harvester

Feedback is highly 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/61c42faf-be8d-4b51-9b90-9515b21ffc1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reflect Call method on nested struct

[Sotirios Mantziaris]

Hi Max, 
this makes the config even simpler since i do not need to be sure that the 
field is nil.
I will try this out for sure.

On Wednesday, May 29, 2019 at 1:56:14 PM UTC+3, Max wrote:
>
> There is another improvement you can do: you are currently using
>
> cfg := Config{Name: }
> r := reflect.ValueOf(cfg)
>
> which means that 'r' will contain a copy of 'cfg' and will not be settable.
> If instead you use:
>
> r := reflect.ValueOf().Elem()
>
> then r will contain a *pointer* to the original 'cfg' and can modify it 
> (the reflect.Value 'r' is settable).
> In turn, this also allows to declare 'Config' as follows:
> ```
> type Config struct {
> Name String
> }
> ```
> i.e. removes the need to use a *pointer* to String.
> You also need some minor adjustments to the rest of the code...
>
> A complete example is:
>
> https://play.golang.org/p/AxPE0K_ivxP
>
> On Wednesday, May 29, 2019 at 11:56:42 AM UTC+2, Sotirios Mantziaris wrote:
>>
>> Ok, found it. I should have used the reflect.ValueOf...
>>
>> On Wednesday, May 29, 2019 at 12:53:13 PM UTC+3, Sotirios Mantziaris 
>> wrote:
>>>
>>> I did found out that the setter method has to accept a pointer to string.
>>> I have a complete example now which unfortunately don't work correclty. 
>>> The value should change but it is emptied out.
>>>
>>> https://play.golang.org/p/OPZKltApEhF
>>>
>>> What am i missing?
>>>
>>> On Wednesday, May 29, 2019 at 10:46:32 AM UTC+3, Jan Mercl wrote:
>>>>
>>>> On Wed, May 29, 2019 at 9:42 AM Sotirios Mantziaris 
>>>>  wrote: 
>>>>
>>>> > I am getting the nested "Name" struct but there are no methods to 
>>>> call. 
>>>> > What am i doing wrong (besides using reflection :))? 
>>>>
>>>> The method has a pointer receiver: 
>>>> https://play.golang.org/p/qjhqSvhE9PL 
>>>>
>>>

-- 
You received this message because you are subscribed to the Google 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/f121de4b-95a3-4a9b-9084-7672a8e20d34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reflect Call method on nested struct

[Sotirios Mantziaris]

Ok, found it. I should have used the reflect.ValueOf...

On Wednesday, May 29, 2019 at 12:53:13 PM UTC+3, Sotirios Mantziaris wrote:
>
> I did found out that the setter method has to accept a pointer to string.
> I have a complete example now which unfortunately don't work correclty. 
> The value should change but it is emptied out.
>
> https://play.golang.org/p/OPZKltApEhF
>
> What am i missing?
>
> On Wednesday, May 29, 2019 at 10:46:32 AM UTC+3, Jan Mercl wrote:
>>
>> On Wed, May 29, 2019 at 9:42 AM Sotirios Mantziaris 
>>  wrote: 
>>
>> > I am getting the nested "Name" struct but there are no methods to call. 
>> > What am i doing wrong (besides using reflection :))? 
>>
>> The method has a pointer receiver: https://play.golang.org/p/qjhqSvhE9PL 
>>
>

-- 
You received this message because you are subscribed to the Google 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/e2eb5584-242c-4144-ad32-a42583ee8cfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reflect Call method on nested struct

[Sotirios Mantziaris]

I did found out that the setter method has to accept a pointer to string.
I have a complete example now which unfortunately don't work correclty. The 
value should change but it is emptied out.

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

What am i missing?

On Wednesday, May 29, 2019 at 10:46:32 AM UTC+3, Jan Mercl wrote:
>
> On Wed, May 29, 2019 at 9:42 AM Sotirios Mantziaris 
> > wrote: 
>
> > I am getting the nested "Name" struct but there are no methods to call. 
> > What am i doing wrong (besides using reflection :))? 
>
> The method has a pointer receiver: https://play.golang.org/p/qjhqSvhE9PL 
>

-- 
You received this message because you are subscribed to the Google 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/001a34f6-163e-45fa-84ce-b10214b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reflect Call method on nested struct

[Sotirios Mantziaris]

you are a live saver. thanks very much.
reflection is of of these things in any language i suppose.

On Wed, 29 May 2019 at 10:46, Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, May 29, 2019 at 9:42 AM Sotirios Mantziaris
>  wrote:
>
> > I am getting the nested "Name" struct but there are no methods to call.
> > What am i doing wrong (besides using reflection :))?
>
> The method has a pointer receiver: https://play.golang.org/p/qjhqSvhE9PL
>


-- 
Regards,

S. Mantziaris

-- 
You received this message because you are subscribed to the Google 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/CAEGsCe2AfWreDBbs4OJy8xSxi0Xs-ibxw%3DB4X%2BRwSJpwx60TNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] reflect Call method on nested struct

[Sotirios Mantziaris]

Hi,

i have a nested struct and i want to call a method on a field.


type String struct {
value string
}

func (s *String) Set(value string) {
s.value = value
}

type Config struct {
Name String
}


I am getting the nested "Name" struct but there are no methods to call.
What am i doing wrong (besides using reflection :))?

Check out the playground link?
https://play.golang.org/p/XSRG5rFWdhq

-- 
You received this message because you are subscribed to the Google 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/83c973f9-429d-4b8b-a7a6-31fd048b9c7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Data race question in config package of harvester

[Sotirios Mantziaris]

Thanks for the clarification Robert.

On Sunday, May 26, 2019 at 9:50:56 PM UTC+3, Robert Engels wrote:
>
> I was referring to updating a reference to a string, which can be updated 
> atomically. 
>
> This is an advantage that Java offers over Go for concurrent programming. 
> Since everything is reference you don’t face this distinction. Which is why 
> most Go uses channels, which are implemented with locks. 
>
> > On May 26, 2019, at 1:16 PM, Jan Mercl <0xj...@gmail.com > 
> wrote: 
> > 
> > On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris 
> > > wrote: 
> > 
> >> From what i understand you propose to create a new object and switch 
> out the old one with the new one using the atomic package of go. 
> > 
> > That cannot work. String is a multi word value. There's nothing in the 
> > atomic package that can update a multi word value. However, a pointer 
> > to anything _can_ be updated atomically. 
> > 
> > You cannot "safely" cheat on the data race. As said before, you must 
> > synchronize (the readers vs writers). There's no other option. 
> > 
> > -- 
> > You received this message because you 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/CAA40n-XTGeeN%3D%3D7R7QMc22KMs_iTWgO4Z%3DWfqoKaFkftenY-7Q%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/cde4e8b0-a104-4429-9f30-94cda14332b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Data race question in config package of harvester

[Sotirios Mantziaris]

I was thrown of by the previous comment.
I think i will create some "atomic" types that handle using mutexes with 
setter and getter methods.
Thanks Jan

On Sunday, May 26, 2019 at 9:17:44 PM UTC+3, Jan Mercl wrote:
>
> On Sun, May 26, 2019 at 8:05 PM Sotirios Mantziaris 
> > wrote: 
>
> > From what i understand you propose to create a new object and switch out 
> the old one with the new one using the atomic package of go. 
>
> That cannot work. String is a multi word value. There's nothing in the 
> atomic package that can update a multi word value. However, a pointer 
> to anything _can_ be updated atomically. 
>
> You cannot "safely" cheat on the data race. As said before, you must 
> synchronize (the readers vs writers). There's no other option. 
>

-- 
You received this message because you are subscribed to the Google 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/57967151-532b-4e32-bbed-f4c0eb2a7038%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Data race question in config package of harvester

[Sotirios Mantziaris]

>From what i understand you propose to create a new object and switch out 
the old one with the new one using the atomic package of go.
If that is the case i cannot use it since i don't control the field 
directly.
I am using the SetString method of the Value struct in the reflect package.

// SetString sets v's underlying value to x.
// It panics if v's Kind is not String or if CanSet() is false.
func (v Value) SetString(x string) {
v.mustBeAssignable()
v.mustBe(String)
*(*string)(v.ptr) = x
}



On Sunday, May 26, 2019 at 8:51:59 PM UTC+3, Robert Engels wrote:
>
> Ignore the incorrect comments from the others. There are many valid cases 
> where relaxed concurrency rules apply and you don’t need synchronization 
> just atomic ops (and with certain platform this is not needed - eg java 
> volatile)That is why GC systems can outperform non GC systems in concurrent 
> scenarios. But you need to allocate new objects not modify existing ones (a 
> big reason GC platform strings are usually immutable). You can do the same 
> in Go. 
>
> On May 26, 2019, at 11:17 AM, Sotirios Mantziaris  > wrote:
>
> I understand, i have to synchronize access...
> Coming from another language i had some guarantees on some assignments 
> mostly int. A string might be a issue here of course...
> I have to refactor my code in order to make is safe.
>
> thanks.
>
> On Sunday, May 26, 2019 at 6:13:56 PM UTC+3, Jan Mercl wrote:
>>
>> On Sun, May 26, 2019 at 4:03 PM Sotirios Mantziaris 
>>  wrote: 
>>
>> > Let's assume that the string field Name has the value `Mr. Smith` and 
>> we change this to  `Mr. Anderson` in the goroutine, what are the possible 
>> values that i could bet on a read? 
>> > 
>> > If these are either `Mr. Smith` or `Mr. Anderson` i am very ok with 
>> that because i want the value to be eventually consistent. 
>>
>> That would be the only possible outcomes iff a multi word value is 
>> updated atomically. 
>>
>> > If there is another possible outcome then i need to synchronize the 
>> access and refactor a lot. 
>>
>> Any outcome is possible with a data race. One of those that are often 
>> seen in practices is, obviously, `Mr. Ander`. Another is that the app 
>> will segfault. Also, the Go memory model does not guarantee one 
>> goroutine will _ever_ observe a change made by a different goroutine 
>> concurrently but without proper synchronization. The compiler if free 
>> to consider all values not explicitly mutated by a code path to never 
>> change without synchronization. 
>>
>> tl;dr: There's no safe way to ignore a data race. 
>>
> -- 
> You received this message because you 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/9abf1f2b-00bf-4346-b429-e40617997237%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/9abf1f2b-00bf-4346-b429-e40617997237%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/7bf75b7a-322e-40c4-b78f-d2427fa275e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Data race question in config package of harvester

[Sotirios Mantziaris]

I understand, i have to synchronize access...
Coming from another language i had some guarantees on some assignments 
mostly int. A string might be a issue here of course...
I have to refactor my code in order to make is safe.

thanks.

On Sunday, May 26, 2019 at 6:13:56 PM UTC+3, Jan Mercl wrote:
>
> On Sun, May 26, 2019 at 4:03 PM Sotirios Mantziaris 
> > wrote: 
>
> > Let's assume that the string field Name has the value `Mr. Smith` and we 
> change this to  `Mr. Anderson` in the goroutine, what are the possible 
> values that i could bet on a read? 
> > 
> > If these are either `Mr. Smith` or `Mr. Anderson` i am very ok with that 
> because i want the value to be eventually consistent. 
>
> That would be the only possible outcomes iff a multi word value is 
> updated atomically. 
>
> > If there is another possible outcome then i need to synchronize the 
> access and refactor a lot. 
>
> Any outcome is possible with a data race. One of those that are often 
> seen in practices is, obviously, `Mr. Ander`. Another is that the app 
> will segfault. Also, the Go memory model does not guarantee one 
> goroutine will _ever_ observe a change made by a different goroutine 
> concurrently but without proper synchronization. The compiler if free 
> to consider all values not explicitly mutated by a code path to never 
> change without synchronization. 
>
> tl;dr: There's no safe way to ignore a data race. 
>

-- 
You received this message because you are subscribed to the Google 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/9abf1f2b-00bf-4346-b429-e40617997237%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Data race question in config package of harvester

[Sotirios Mantziaris]

Let's assume that the string field Name has the value `Mr. Smith` and we 
change this to  `Mr. Anderson` in the goroutine, what are the possible 
values that i could bet on a read?
If these are either `Mr. Smith` or `Mr. Anderson` i am very ok with that 
because i want the value to be eventually consistent. If there is another 
possible outcome then i need to synchronize the access and refactor a lot.

On Sunday, May 26, 2019 at 4:58:02 PM UTC+3, Jan Mercl wrote:
>
> On Sun, May 26, 2019 at 3:45 PM Sotirios Mantziaris 
> > wrote: 
>
> > Is there a chance that reading and assigning values might not be atomic? 
>
> Accessing a the full multi word value is non-atomic on most, if not 
> all architectures. 
>

-- 
You received this message because you are subscribed to the Google 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/8074cb8e-5982-40cf-911d-90ea59205c76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Data race question in config package of harvester

[Sotirios Mantziaris]

i am working on a library for configuration named harvester(
https://github.com/taxibeat/harvester), which will be soon properly open 
sourced, where i can dynamically reconfigure the configuration from an 
outside system (consul).

The user provides a struct with some tags

type testConfig struct {
Namestring  `consul:"harvester1/name"`
}

the consul key is monitored and when it changes the filed Name is set via 
reflection `SetString(value)`.

the above runs in a go routine.

The struct/field is propagated via pointer to the rest of the code of the 
application so that a change in the struct is reflected.

Understandably the race detector fails because the goroutine changes the 
value and someone else is reading it.

There is always only one that writes and multiple that read.
Worst case you get the old value, best case you get the new value.
Is there a chance that reading and assigning values might not be atomic?


-- 
You received this message because you are subscribed to the Google 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/95ac522d-7cd4-4c34-b2cd-b00387cad849%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Forking/transfering a repository and import paths

[Sotirios Mantziaris]

I will try some of the suggestion in this topic to see what works out.
I will open a feature request in the golang repo for forking support. 

On Saturday, December 29, 2018 at 6:56:32 AM UTC+2, Nathan Fisher wrote:
>
> TLDR
>
> > Is it possible to fork a repo and change the import path of the 
> repository?
>
> Not in one step with the github “click to fork”. You need to do one of the 
> following:
>
> 1. Create a new empty remote repo, remap imports, and push to the new 
> remote.
> 2. Fork, update imports, push.
> 3. Assuming vanity URL is used, fork and then update the vanity urls meta 
> tag.
>
> > Is it possible to have:
> > both repos
> yes but I would try to deprecate one as “archived/historical”.
>
> > every repo with it's own import path
> yes, it does by nature of being different urls
>
> > code exchange between them
> yes, but I’d avoid if possible. You’ll need to remap imports to match the 
> repo so it’s not a simple push to both remotes.
>
> —
>
> You can use gofmt to remap the import paths. If you’re aim is to “sync” 
> repos (I’m not clear why you’d want this aside from a clearance process for 
> making corp stuff public) then you could encode the commands in a script or 
> make target and trigger them as part of a “publishing process”. Relative 
> import paths were available at one point but they are now 
> deprecated/unavailable. In theory it allowed ignorance of the SCMs root at 
> the sacrifice of not being go gettable and probably a number of other 
> issues which resulted in its removal.
>
> Godoc isn’t essential infrastructure in my opinion, you can serve docs 
> locally in a pinch and I often do this while working offline in planes, 
> trains, and automobiles. Introducing a registry however adds a failure 
> domain/security concern that can break or be compromised. If githubs down 
> and your repo is on github it’s the same failure domain so you’re arguably 
> no worse/better off if your deps are there. Committing vendor where 
> possible minimises the failure domains further and generally yields faster 
> CI builds as a side benefit IME.
>
> Another option might be abusing vanity urls if the objective is to support 
> ongoing development in both repos (eg returning different meta tags based 
> on a work IP vs not or a local /etc/hosts override to a different vanity 
> url host). I’m not terribly familiar with them but in theory it should 
> allow the same import path in both repos but it would likely result in some 
> confusing issues. I don’t think it’s a great idea but it might work for 
> your scenario.
> On Fri, Dec 28, 2018 at 18:24, Sotirios Mantziaris  > wrote:
>
>> If i understand it correctly the proposed solutions does not solve the 
>> problem of forking repos.
>> The ideal solution would be to have a import path agnostic of the repo 
>> location so that a fork could be up and downstream compatible.
>>
>> On Thursday, December 13, 2018 at 12:32:11 AM UTC+2, Ian Lance Taylor 
>> wrote:
>>
>>> On Wed, Dec 12, 2018 at 8:08 AM Robert Engels  
>>> wrote: 
>>> > 
>>> > I am pretty sure that the correct solution is to decouple the package 
>>> from its location. And a global Go registry can tell Go get where that 
>>> package can currently be found. 
>>>
>>> You don't need a global registry.  Or, rather, the global registry can 
>>> be DNS.  You can set up your own trivial redirector, using a meta tag, 
>>> as discussed at https://golang.org/cmd/go/#hdr-Remote_import_paths . 
>>> Or you can use an existing general purpose redirector such as 
>>> gopkg.in.  Either way you can enforce this with an import comment as 
>>> discussed at https://golang.org/cmd/go/#hdr-Import_path_checking . 
>>>
>>> Ian 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> - sent from my mobile
>

-- 
You received this message because you are subscribed to the Google 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] Forking/transfering a repository and import paths

[Sotirios Mantziaris]

If i understand it correctly the proposed solutions does not solve the 
problem of forking repos.
The ideal solution would be to have a import path agnostic of the repo 
location so that a fork could be up and downstream compatible.

On Thursday, December 13, 2018 at 12:32:11 AM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Dec 12, 2018 at 8:08 AM Robert Engels  > wrote: 
> > 
> > I am pretty sure that the correct solution is to decouple the package 
> from its location. And a global Go registry can tell Go get where that 
> package can currently be found. 
>
> You don't need a global registry.  Or, rather, the global registry can 
> be DNS.  You can set up your own trivial redirector, using a meta tag, 
> as discussed at https://golang.org/cmd/go/#hdr-Remote_import_paths . 
> Or you can use an existing general purpose redirector such as 
> gopkg.in.  Either way you can enforce this with an import comment as 
> discussed at https://golang.org/cmd/go/#hdr-Import_path_checking . 
>
> 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] Forking/transfering a repository and import paths

[Sotirios Mantziaris]

Hi, if i understood correctly this solves the location of the repository
path but the repo path will still point to the old repo.
It would be nice if the repo location could be anywhere and the import path
anything e.g. hosted on any machine with the root package name be something
different  (location agnostic).
The mod file or the project could have simple module name e.g. module
patron
and in the project that imports it: require patron v0.7.4
github.com/mantzas/patron.

When you `go get` a project for import you provide the location and `go
get` could read the module name from the mod file and import it.
This way you could solve the fork problem by just `go get` from another
location. forking would work.

On Thu, Dec 13, 2018 at 12:31 AM Ian Lance Taylor  wrote:

> On Wed, Dec 12, 2018 at 8:08 AM Robert Engels 
> wrote:
> >
> > I am pretty sure that the correct solution is to decouple the package
> from its location. And a global Go registry can tell Go get where that
> package can currently be found.
>
> You don't need a global registry.  Or, rather, the global registry can
> be DNS.  You can set up your own trivial redirector, using a meta tag,
> as discussed at https://golang.org/cmd/go/#hdr-Remote_import_paths .
> Or you can use an existing general purpose redirector such as
> gopkg.in.  Either way you can enforce this with an import comment as
> discussed at https://golang.org/cmd/go/#hdr-Import_path_checking .
>
> Ian
>


-- 
Regards,

S. Mantziaris

-- 
You received this message because you are subscribed to the Google 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: Forking/transfering a repository and import paths

[Sotirios Mantziaris]

would this one the problem of forking or transfer to another account? The
go module path would still be the old one.
Like mentioned before it would be nice if the hosting path and the module
path could be different e.g. hosting path github.com/mantzas/test module
path "test".

On Thu, Dec 13, 2018 at 12:03 AM Tamás Gulácsi  wrote:

> With go modules you can import whatever/btcutil and force to be ../btcutil
> (see the replace directive).
>
> --
> 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/E_TK2n9E-to/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.
>


-- 
Regards,

S. Mantziaris

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

[go-nuts] Re: Forking/transfering a repository and import paths

[Sotirios Mantziaris]

I was under the impression that go modules would do that kind of separation.
When creating a module you define the module path. If the project is hosted 
in github, bitbucket or anywhere else should not matter.
when calling go get github.com/user/application you refer just to the path 
where the repo is hosted. the import path should be the module path in the 
go.mod file.
Unfortunatelly i am not that experienced with modules. Is someone more 
experienced in go modules?

On Wednesday, December 12, 2018 at 7:41:57 PM UTC+2, Louki Sumirniy wrote:
>
> I have done this many times. Some repositories are more of a pain than 
> others to move. I was amused to learn after having done this with 
> github.com/btcsuite/btcd, that the btcjson, btcec, btcutil and btclog 
> repos all were separate but quite tightly bound both to each other and it 
> took me about half a day to fix it. Part of my solution was copying those 
> repos, removing the .git folder. I could have rather forked all of them, 
> but those 4 in particular and the main btcd were very tangled and hard to 
> separate.
>
> My opinion is that there should be a simple way to refer to orthogonal 
> repos, and sub-folders, with simple relative paths. So instead of "
> github.com/btcsuite/btcd/blockchain" I can just say "./blockchain" or 
> instead of "github.com/btcsuite/btclog" I can say "../btclog" and the 
> rest is inferred from the module spec and/or gopath location. 
>
> I use Visual Studio Code (it has the best go toolchain integration I am 
> aware of) and its search-in-repository functions are quite good, but it's 
> easy to make a mistake and accidentally cast too wide a net, and the 
> poor-man's-cut-down-for-no-reason regex searching doesn't help either.
>
> It's not difficult, just tedious, and it would be nice if there was 
> relative paths allowed for imports.
>
> On Wednesday, 12 December 2018 13:12:53 UTC+1, Sotirios Mantziaris wrote:
>>
>> Hi,
>>
>> i want to move a repo from my github account to another one. Goal is to 
>> have a new import path for the new forked repository.
>> There are 2 ways of achieving the move:
>>
>>- Forking
>>- Transfer repository
>>
>> Is it possible to fork a repo and change the import path of the 
>> repository?
>>
>> If the transfer option is chosen we just have to change all imports in 
>> the code, which severs the ties for the originating project.
>>
>> Is it possible to have:
>>
>>- both repos
>>- every repo with it's own import path
>>- code exchange between them
>>
>> What are the options?
>>
>

-- 
You received this message because you are subscribed to the Google 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] Forking/transfering a repository and import paths

[Sotirios Mantziaris]

exactly that robert. :)

On Wed, Dec 12, 2018 at 5:43 PM Robert Engels  wrote:

> I think he is pointing out the problem I’ve asked about many times that
> using the specified import path so ‘go get’ works is a problem. If I want
> to move my repos to another account all referencing code breaks.
>
> The import paths need a logical reference.
>
> Think Java and package names. The package name remains constant, where it
> is located/retrieved from changes all the time (classpath)
>
> I am assuming I’ve always misunderstood this, but nothing that was ever
> stated cleared it up, so I just went with, well I guess I don’t understand
> and move along...
>
> On Dec 12, 2018, at 9:36 AM, Wagner Riffel  wrote:
>
> Go has nothing to do with github, you can have any import path and how
> many repos you like as long as it exists on your file system inside
> $GOPATH/src
> -wgr
>
> On Wed, Dec 12, 2018, 10:13 AM Sotirios Mantziaris 
> wrote:
>
>> Hi,
>>
>> i want to move a repo from my github account to another one. Goal is to
>> have a new import path for the new forked repository.
>> There are 2 ways of achieving the move:
>>
>>- Forking
>>- Transfer repository
>>
>> Is it possible to fork a repo and change the import path of the
>> repository?
>>
>> If the transfer option is chosen we just have to change all imports in
>> the code, which severs the ties for the originating project.
>>
>> Is it possible to have:
>>
>>- both repos
>>- every repo with it's own import path
>>- code exchange between them
>>
>> What are the options?
>>
>> --
>> You received this message because you are subscribed to the Google 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.
>
>

-- 
Regards,

S. Mantziaris

-- 
You received this message because you are subscribed to the Google 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] Forking/transfering a repository and import paths

[Sotirios Mantziaris]

Hi,

i want to move a repo from my github account to another one. Goal is to 
have a new import path for the new forked repository.
There are 2 ways of achieving the move:

   - Forking
   - Transfer repository

Is it possible to fork a repo and change the import path of the repository?

If the transfer option is chosen we just have to change all imports in the 
code, which severs the ties for the originating project.

Is it possible to have:

   - both repos
   - every repo with it's own import path
   - code exchange between them

What are the options?

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

Re: [go-nuts] go modules and Dockerfile

[Sotirios Mantziaris]

Awesome thanks

On Wednesday, September 19, 2018 at 10:40:30 PM UTC+3, Justin Israel wrote:
>
>
>
> On Thu, Sep 20, 2018, 6:09 AM Sotirios Mantziaris  > wrote:
>
>> hi,
>>
>> i am trying to build a container that supports modules and i get the 
>> following error:
>>
>> ↳ docker build . -t test  
>> 
>>  1 ↵  
>> 4.91G RAM  0.00K SWP  21:04:00
>> Sending build context to Docker daemon  16.65MB
>> Step 1/6 : FROM golang:latest as builder
>>  ---> fb7a47d8605b
>> Step 2/6 : COPY . ./
>>  ---> Using cache
>>  ---> 95a6b0284991
>> Step 3/6 : RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o 
>> test ./cmd/test/main.go
>>  ---> Running in f09b924aa3e9
>> $GOPATH/go.mod exists but should not
>> The command '/bin/sh -c CGO_ENABLED=0 GOOS=linux go build -a 
>> -installsuffix cgo -o test ./cmd/test/main.go' returned a non-zero code: 1
>>
>> The docker file looks like this.
>>
>> FROM golang:latest as builder
>> COPY . ./
>> RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o test 
>> ./cmd/test/main.go 
>>
>> FROM scratch
>> COPY --from=builder test .
>> CMD ["./test"]
>>
>> any ideas how to solve this?
>>
>
> The golang image sets WORKDIR $GOPATH, and you don't modify it at all. So 
> you are copying your project files to $GOPATH
>
> Try doing 
>
> WORKDIR $GOPATH/src/myapp
>
> Or to some location outside $GOPATH
>
>> -- 
>> You received this message because you are subscribed 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.

[go-nuts] go modules and Dockerfile

[Sotirios Mantziaris]

hi,

i am trying to build a container that supports modules and i get the 
following error:

↳ docker build . -t test

   1 ↵  
4.91G RAM  0.00K SWP  21:04:00
Sending build context to Docker daemon  16.65MB
Step 1/6 : FROM golang:latest as builder
 ---> fb7a47d8605b
Step 2/6 : COPY . ./
 ---> Using cache
 ---> 95a6b0284991
Step 3/6 : RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o 
test ./cmd/test/main.go
 ---> Running in f09b924aa3e9
$GOPATH/go.mod exists but should not
The command '/bin/sh -c CGO_ENABLED=0 GOOS=linux go build -a -installsuffix 
cgo -o test ./cmd/test/main.go' returned a non-zero code: 1

The docker file looks like this.

FROM golang:latest as builder
COPY . ./
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o test 
./cmd/test/main.go 

FROM scratch
COPY --from=builder test .
CMD ["./test"]

any ideas how to solve this?

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

[go-nuts] Re: Delve 1.1.0 is released

[Sotirios Mantziaris]

Thanks very much for making delve. Without a debugger go might not be on my 
radar!

On Friday, August 17, 2018 at 2:01:54 AM UTC+3, Derek Parker wrote:
>
> Announcing Delve v1.1.0!
> Tons of fixes and improvements including: * Go 1.11 support * Initial 
> support for function & method calls (still new, still improving) * New 
> commands / options * Logging improvements * A lot more! Check out the full 
> changelog here 
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google 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] streadway/amqp (RabbitMQ) manual Ack does not work after first message

[Sotirios Mantziaris]

c'mon, this is so stupid...
thanks man very much, this was actually the problem!
Kudos for finding the culprit!

On Wednesday, August 15, 2018 at 12:44:20 AM UTC+3, Justin Israel wrote:
>
>
>
> On Wed, Aug 15, 2018 at 9:33 AM Sotirios Mantziaris  > wrote:
>
>> I can see over the wire that i get messages from the server with 
>> Basic.Delivery.
>> The messages do not pop up out of the channel that channel.Consume 
>> returns when creating the connection.
>> I might read some where that channels do not play well with threads. I 
>> wonder if it is the same with goroutines, because i get the messages one 
>> one goroutine, send it to another via a channel where the messages get Ack 
>> or Nack.
>>
>> You said that your application has a similar pattern. Is the channel and 
>> Ack, Nack on the same goroutine? do you have code that i can look into?
>>
>
> My application is internal at work, so I can't share it. But I took a look 
> at your code and I think this might be your problem:
>
> https://github.com/mantzas/patron/blob/amqp-lock/async/amqp/amqp.go#L119
>
> You are only selecting once on the delivery channel, without a for loop. 
> So you pull one message and your goroutine exits and never delivers another 
> message.
>
> You should be fine sharing the messages between goroutines. All that 
> matters is that the message acks itself back with the tag you set.
>  
>
>>
>> On Wednesday, August 15, 2018 at 12:24:18 AM UTC+3, Justin Israel wrote:
>>
>>>
>>>
>>> On Wed, Aug 15, 2018 at 8:05 AM Sotirios Mantziaris  
>>> wrote:
>>>
>>>> I have actually opened a thread in the rabbitmq-users list where i 
>>>> checked through wireshark what goes over the wire. It is actually pretty 
>>>> nice to see the flow.
>>>> I have cross posted since i did not know if it is rabbitmq or my go 
>>>> code...
>>>> it seems that i get the next message from the wire but the code does 
>>>> not get it at all...
>>>>
>>>
>>> If I am reading that properly, you are saying that your message handler 
>>> is not actually getting triggered at all for subsequent messages? That 
>>> would mean you have some kind of blocking problem in your goroutines and 
>>> channels. I thought initially you were saying that you verified the handler 
>>> was constantly receiving messages and calling ack() but the ack never makes 
>>> it back to Rabbitmq
>>>
>>>
>>>> On Tuesday, August 14, 2018 at 10:59:15 PM UTC+3, Justin Israel wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 15, 2018, 2:14 AM Sotirios Mantziaris  
>>>>> wrote:
>>>>>
>>>>>> hi,
>>>>>>
>>>>>> i have setup a "consumer" for a rabbitmq queue. Every delivery is put 
>>>>>> in a channel which is picked up by a goroutine.
>>>>>> After processing the delivery is then Ack or Nack based on the 
>>>>>> success of the processing.
>>>>>> It seems that the first one is processed ok but the rest cannot be 
>>>>>> Ack/Nack.
>>>>>> The ui of rabbitmq shows every message in a unacked state, which 
>>>>>> probably means that the consumer gets the message from the queue but 
>>>>>> something prevents it for being put in the above mentioned channel.
>>>>>>
>>>>>> The consume part of the queue can be found here : 
>>>>>> https://github.com/mantzas/patron/blob/amqp-lock/async/amqp/amqp.go
>>>>>> The processing goroutine can be found here: 
>>>>>> https://github.com/mantzas/patron/blob/amqp-lock/async/component.go
>>>>>>
>>>>>> Does anybody have a idea?
>>>>>>
>>>>>
>>>>> I have an application with a similar pattern where is manually acks 
>>>>> each message after the processing succeeds. So I can check your logic 
>>>>> against mine. In the meantime, can you clarify if you confirmed that 
>>>>> processing always happens locally and the ack does get called every time, 
>>>>> but you are just not seeing it deliver the ack to Rabbitmq? 
>>>>>
>>>> -- 
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "golang-nuts" group.
>>>>>>
>>>>> To unsubscribe from this group and stop receiv

Re: [go-nuts] streadway/amqp (RabbitMQ) manual Ack does not work after first message

[Sotirios Mantziaris]

I have actually opened a thread in the rabbitmq-users list where i checked 
through wireshark what goes over the wire. It is actually pretty nice to 
see the flow.
I have cross posted since i did not know if it is rabbitmq or my go code...
it seems that i get the next message from the wire but the code does not 
get it at all...

On Tuesday, August 14, 2018 at 10:59:15 PM UTC+3, Justin Israel wrote:
>
>
>
> On Wed, Aug 15, 2018, 2:14 AM Sotirios Mantziaris  > wrote:
>
>> hi,
>>
>> i have setup a "consumer" for a rabbitmq queue. Every delivery is put in 
>> a channel which is picked up by a goroutine.
>> After processing the delivery is then Ack or Nack based on the success of 
>> the processing.
>> It seems that the first one is processed ok but the rest cannot be 
>> Ack/Nack.
>> The ui of rabbitmq shows every message in a unacked state, which probably 
>> means that the consumer gets the message from the queue but something 
>> prevents it for being put in the above mentioned channel.
>>
>> The consume part of the queue can be found here : 
>> https://github.com/mantzas/patron/blob/amqp-lock/async/amqp/amqp.go
>> The processing goroutine can be found here: 
>> https://github.com/mantzas/patron/blob/amqp-lock/async/component.go
>>
>> Does anybody have a idea?
>>
>
> I have an application with a similar pattern where is manually acks each 
> message after the processing succeeds. So I can check your logic against 
> mine. In the meantime, can you clarify if you confirmed that processing 
> always happens locally and the ack does get called every time, but you are 
> just not seeing it deliver the ack to Rabbitmq? 
>
>> -- 
>> You received this message because you are subscribed 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.

[go-nuts] streadway/amqp (RabbitMQ) manual Ack does not work after first message

[Sotirios Mantziaris]

hi,

i have setup a "consumer" for a rabbitmq queue. Every delivery is put in a 
channel which is picked up by a goroutine.
After processing the delivery is then Ack or Nack based on the success of 
the processing.
It seems that the first one is processed ok but the rest cannot be Ack/Nack.
The ui of rabbitmq shows every message in a unacked state, which probably 
means that the consumer gets the message from the queue but something 
prevents it for being put in the above mentioned channel.

The consume part of the queue can be found here 
: https://github.com/mantzas/patron/blob/amqp-lock/async/amqp/amqp.go
The processing goroutine can be found 
here: https://github.com/mantzas/patron/blob/amqp-lock/async/component.go

Does anybody have a idea?

-- 
You received this message because you are subscribed to the Google 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: [ANN] parwork - a fork-join package for processing work in parallel written in go

[Sotirios Mantziaris]

interesting, but it does not do the same as parwork.
parwork set's up a fork-join pipeline which processes the work of channels.
Run does limit functions run in parallel.

On Thursday, March 15, 2018 at 2:53:36 PM UTC+2, rog wrote:
>
> You might be interested to look at 
> https://godoc.org/github.com/juju/utils/parallel#Run, a slightly 
> simpler approach to the same issue, and just about as general, I 
> think. 
>
> On 15 March 2018 at 08:19, Sotirios Mantziaris <smant...@gmail.com 
> > wrote: 
> > since the lack of generics i am trying to avoid interface{} as much as 
> > possible. 
> > 
> > On Thursday, March 15, 2018 at 1:03:14 AM UTC+2, matthe...@gmail.com 
> wrote: 
> >> 
> >> Hi Sotirios, 
> >> 
> >> Why not something like this? 
> >> 
> >> // Stops and returns if any error is encountered by a work function, 
> >> otherwise returns nil. 
> >> // Processes work at the pace of runtime.NumCPU() parallelization. 
> >> func Process(callback func(interface{}), work ...func() (interface{}, 
> >> error)) error 
> >> 
> >> Matt 
> >> 
> >> On Wednesday, March 14, 2018 at 3:54:24 PM UTC-5, Sotirios Mantziaris 
> >> wrote: 
> >>> 
> >>> Hi, 
> >>> 
> >>> 
> >>> i have created a package which uses the fork-join model to parallelize 
> >>> work. 
> >>> 
> >>> Check out my blog and the Github repository. 
> >>> 
> >>> 
> >>> Any feedback is highly welcome. 
> >>> 
> >>> 
> >>> 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

[go-nuts] Re: [ANN] parwork - a fork-join package for processing work in parallel written in go

[Sotirios Mantziaris]

since the lack of generics i am trying to avoid interface{} as much as 
possible.

On Thursday, March 15, 2018 at 1:03:14 AM UTC+2, matthe...@gmail.com wrote:
>
> Hi Sotirios,
>
> Why not something like this?
>
> // Stops and returns if any error is encountered by a work function, 
> otherwise returns nil.
> // Processes work at the pace of runtime.NumCPU() parallelization.
> func Process(callback func(interface{}), work ...func() (interface{}, 
> error)) error
>
> Matt
>
> On Wednesday, March 14, 2018 at 3:54:24 PM UTC-5, Sotirios Mantziaris 
> wrote:
>>
>> Hi,
>>
>>
>> i have created a package which uses the fork-join model to parallelize 
>> work.
>>
>> Check out my blog 
>> <http://blog.mantziaris.eu/blog/2018/03/14/parallelize-work-using-parwork/>and
>>  
>> the Github <https://github.com/mantzas/parwork>repository.
>>
>>
>> Any feedback is highly welcome.
>>
>>
>> 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.

[go-nuts] [ANN] parwork - a fork-join package for processing work in parallel written in go

[Sotirios Mantziaris]

Hi,


i have created a package which uses the fork-join model to parallelize work.

Check out my blog 
and 
the Github repository.


Any feedback is highly welcome.


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.

[go-nuts] Debugging unit tests in go

[Sotirios Mantziaris]

Visual studio code with go extension which uses delve. Just works like a charm.

-- 
You received this message because you are subscribed to the Google 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: Why is there no standard `uuid` package?

[Sotirios Mantziaris]

i agree that since there exist a RFC it should not be that much of a 
problem. 

On Friday, February 9, 2018 at 9:52:33 AM UTC+2, Henry wrote:
>
> @axel: The specification for UUID is defined in RFC 4122. You are free to 
> use it or create your own variants. However, the specs is there. 

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

[go-nuts] Re: Why is there no standard `uuid` package?

[Sotirios Mantziaris]

i agree that there should be a std package version of uuid like in almost 
every other language.

On Thursday, February 8, 2018 at 3:43:08 AM UTC+2, 高橋誠二 wrote:
>
> Recently satori/go.uuid took a breaking change of API, and some of 
> frameworks which depend on the package.
> And google/uuid is unstable.
>
> Why Go doesn't have an official uuid package?
> Is there any load map to develop google/uuid and merge it to Go itself?
>
>

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

[go-nuts] Re: Golang crashes windows console

[Sotirios Mantziaris]

hi,

i had the same issue. My fix was to upgrade or downgrade git. The 
latest git version 2.15.0.windows.1 works ok.

On Monday, November 13, 2017 at 5:33:55 PM UTC+2, Patrick Hadlaw wrote:
>
> I've posted my problem on stack overflow and could not fix it!
>
> https://stackoverflow.com/questions/46392778/golang-crashing-windows-console
>
> I'm running Windows 10, installed go through x64 msi installer. Basically, 
> whenever I run Go in cmd with an argument (build, env, list, get...) the 
> program seems to be either closing or crashing the console after completing 
> running. So if I run go build it will work but will close console before I 
> can read any errors. The only way I can use go is by writing all go 
> commands to a file such as:
> go env > file.txt
>

-- 
You received this message because you are subscribed to the Google 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: Zero-dependency, small codebase logger which supports StackDriver (Kubernetes) logging.

[Sotirios Mantziaris]

i see a lot of open source under MIT and Apache-2.0, which is pretty 
straightforward and clean.




On Wednesday, November 8, 2017 at 4:20:11 PM UTC+2, Jan Mercl wrote:
>
> On Wed, Nov 8, 2017 at 3:15 PM Sotirios Mantziaris <smant...@gmail.com 
> > wrote:
>
> > BSD 3-clause? This might be a problem for some.
>
> Why so? Which license would be better?
>
>
> -- 
>
> -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.

[go-nuts] Re: Zero-dependency, small codebase logger which supports StackDriver (Kubernetes) logging.

[Sotirios Mantziaris]

BSD 3-clause? This might be a problem for some.

On Wednesday, November 8, 2017 at 3:41:53 PM UTC+2, Shawn Milochik wrote:
>
>
> http://www.nikola-breznjak.com/blog/go/go-logger-kubernetes-stackdriver-format-compatibility/
>
> We evaluated Apex and other loggers, and had been using logrus, but ended 
> up with an in-house library we like better.
>
> The primary concerns were working with StackDriver for our Google-hosted 
> infrastructure and *simple* syntax for the developer. We hope others will 
> enjoy it as well.
>
> Happy Wednesday!
>
> -- 
> ☕
>

-- 
You received this message because you are subscribed to the Google 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: [Request] Official golang debugger

[Sotirios Mantziaris]

You both make good point to why that might have it's issues.
Taken into account the time mentioned it makes more sense to keep it
separate and have it's own release cycle.
Thanks for your input.

On Tue, Nov 7, 2017 at 1:46 PM Dave Cheney <d...@cheney.net> wrote:

>
>
> On Tuesday, 7 November 2017 22:29:29 UTC+11, Sotirios Mantziaris wrote:
>>
>> Apart from the time it would take to make changes to a tool in the
>> toolchain i could come up with a reason for that:
>>
>> If a new feature gets added to go that would affect the debugger it would
>> be tackled away as part of the release as opposed to wait for the final
>> release and start implementing the new feature after the release.
>>
>
> Anyone can download tip and build it, it almost always builds.
>
>
>> As a example for the above could be the vendor support change that would
>> be in the tool right away or the recent change to pprof not needing the
>> binary to resolve symbols etc.
>>
>
> I don't think these are very compelling arguments
>
> - vendoring is an illusion created by the go tool, the compiler is unaware
> of it.
> - the pprof change affects the pprof files written by the profiler, it is
> unrelated to DWARF information written by the linker.
>
>
>>
>> Some tools a so core and should be in the toolchain like dependency
>> management, debuggers, compiler etc...
>> I had a hard time choosing a dependency management tool as they where so
>> many of them. As soon dep was announced to be the standard tool, i switched
>> immediately to it since this is not something i would like to thing when i
>> write code, it is just tooling.
>>
>> This is just my thought.
>>
>
> I'm on your side here, and my advice is do not yoke your debugging tool to
> the go tool release cycle.
>
>>
>>
>> On Tue, Nov 7, 2017 at 11:33 AM Florin Pățan <flori...@gmail.com> wrote:
>>
> For that tool, which is not the subject of this thread, the maintainers
>>> are willing to pay the price of inclusion in the toolchain.
>>>
>>> As I stated in my original reply,I would hope we don't have to pay the
>>> same price for the debugger.
>>>
>>> I don't understand why anyone thinks that inclusion in the toolchain, as
>>> the toolchain is today is a good idea. The toolchain/standard library is
>>> where all things stop evolving any any significant speed and stop being
>>> able to break compatibil in favor of stability. If we'd have a 3 months
>>> release cycle then this might be a different story.
>>>
>>> However it's ultimately not up to me to decide but I believe that the
>>> more things we have outside of the toolchain / standard library, the
>>> better.
>>>
>>> On Tue, 7 Nov 2017, 09:19 Sotirios Mantziaris, <smant...@gmail.com>
>>> wrote:
>>>
>> https://github.com/golang/dep/wiki/Roadmap
>>>>
>>>> The goal with dep is to be absorbed into the go toolchain. That's the
>>>> path we're on, but it's up to the Go community - you! - to help us see it
>>>> through.
>>>>
>>>> On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan <flori...@gmail.com>
>>>> wrote:
>>>>
>>> dep is not part of the toolchain.
>>>>>
>>>>> On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, <smant...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> would it not make sense them to keep dep out of the std toolchain to
>>>>>> adapt faster to changes?
>>>>>>
>>>>>> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote:
>>>>>>>
>>>>>>> If you reported an issue today, Nov 6, you could be waiting nearly 9
>>>>>>> months to see a fix in the next released version of Go.
>>>>>>>
>>>>>>> A project living outside the standard library has little going
>>>>>>> against it other than you have to compile it yourself.
>>>>>>>
>>>>>>> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I do not know if the times you mentioned are indeed that long.
>>>>>>>> If it is true then you actually have a good argument.
>>>>>>>>
>>>>>>>> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan
>>>>>>>> wrote:
>>>>>&g

Re: [go-nuts] Re: [Request] Official golang debugger

[Sotirios Mantziaris]

Apart from the time it would take to make changes to a tool in the
toolchain i could come up with a reason for that:

If a new feature gets added to go that would affect the debugger it would
be tackled away as part of the release as opposed to wait for the final
release and start implementing the new feature after the release.
As a example for the above could be the vendor support change that would be
in the tool right away or the recent change to pprof not needing the binary
to resolve symbols etc.

Some tools a so core and should be in the toolchain like dependency
management, debuggers, compiler etc...
I had a hard time choosing a dependency management tool as they where so
many of them. As soon dep was announced to be the standard tool, i switched
immediately to it since this is not something i would like to thing when i
write code, it is just tooling.

This is just my thought.


On Tue, Nov 7, 2017 at 11:33 AM Florin Pățan <florinpa...@gmail.com> wrote:

> For that tool, which is not the subject of this thread, the maintainers
> are willing to pay the price of inclusion in the toolchain.
>
> As I stated in my original reply,I would hope we don't have to pay the
> same price for the debugger.
>
> I don't understand why anyone thinks that inclusion in the toolchain, as
> the toolchain is today is a good idea. The toolchain/standard library is
> where all things stop evolving any any significant speed and stop being
> able to break compatibil in favor of stability. If we'd have a 3 months
> release cycle then this might be a different story.
>
> However it's ultimately not up to me to decide but I believe that the more
> things we have outside of the toolchain / standard library, the better.
>
> On Tue, 7 Nov 2017, 09:19 Sotirios Mantziaris, <smantzia...@gmail.com>
> wrote:
>
>> https://github.com/golang/dep/wiki/Roadmap
>>
>> The goal with dep is to be absorbed into the go toolchain. That's the
>> path we're on, but it's up to the Go community - you! - to help us see it
>> through.
>>
>> On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan <florinpa...@gmail.com>
>> wrote:
>>
>>> dep is not part of the toolchain.
>>>
>>> On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, <smantzia...@gmail.com>
>>> wrote:
>>>
>>>> would it not make sense them to keep dep out of the std toolchain to
>>>> adapt faster to changes?
>>>>
>>>> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote:
>>>>>
>>>>> If you reported an issue today, Nov 6, you could be waiting nearly 9
>>>>> months to see a fix in the next released version of Go.
>>>>>
>>>>> A project living outside the standard library has little going against
>>>>> it other than you have to compile it yourself.
>>>>>
>>>>> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote:
>>>>>>
>>>>>> I do not know if the times you mentioned are indeed that long.
>>>>>> If it is true then you actually have a good argument.
>>>>>>
>>>>>> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote:
>>>>>>>
>>>>>>> I hope not. Anything that ends up in the toolchain is slow to change
>>>>>>> and adapt to user needs. If I have a problem with delve today, I can 
>>>>>>> post
>>>>>>> an issue, fix it and get the next version of delve az quick as a few 
>>>>>>> hours.
>>>>>>> If it would be in the toolchain it could take up to six months to get it
>>>>>>> released.
>>>>>>>
>>>>>>> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, <smant...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes i know that, but i wonder if it is time to fully integrate
>>>>>>>> delve in the go toolchain and ship it with every release like dep, 
>>>>>>>> which
>>>>>>>> exists in another repository, but will be fullly integrated into the
>>>>>>>> toolchain and the releases in some future version.
>>>>>>>>
>>>>>>>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Delve is the one towards which the community rally since gdb,
>>>>>>>>> still, doesn't play nice with goroutines. So, for all in

Re: [go-nuts] Re: [Request] Official golang debugger

[Sotirios Mantziaris]

https://github.com/golang/dep/wiki/Roadmap

The goal with dep is to be absorbed into the go toolchain. That's the path
we're on, but it's up to the Go community - you! - to help us see it
through.

On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan <florinpa...@gmail.com> wrote:

> dep is not part of the toolchain.
>
> On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, <smantzia...@gmail.com>
> wrote:
>
>> would it not make sense them to keep dep out of the std toolchain to
>> adapt faster to changes?
>>
>> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote:
>>>
>>> If you reported an issue today, Nov 6, you could be waiting nearly 9
>>> months to see a fix in the next released version of Go.
>>>
>>> A project living outside the standard library has little going against
>>> it other than you have to compile it yourself.
>>>
>>> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote:
>>>>
>>>> I do not know if the times you mentioned are indeed that long.
>>>> If it is true then you actually have a good argument.
>>>>
>>>> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote:
>>>>>
>>>>> I hope not. Anything that ends up in the toolchain is slow to change
>>>>> and adapt to user needs. If I have a problem with delve today, I can post
>>>>> an issue, fix it and get the next version of delve az quick as a few 
>>>>> hours.
>>>>> If it would be in the toolchain it could take up to six months to get it
>>>>> released.
>>>>>
>>>>> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, <smant...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Yes i know that, but i wonder if it is time to fully integrate delve
>>>>>> in the go toolchain and ship it with every release like dep, which exists
>>>>>> in another repository, but will be fullly integrated into the toolchain 
>>>>>> and
>>>>>> the releases in some future version.
>>>>>>
>>>>>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:
>>>>>>>
>>>>>>> Delve is the one towards which the community rally since gdb, still,
>>>>>>> doesn't play nice with goroutines. So, for all intents and purposes, 
>>>>>>> delve
>>>>>>> is the official debugger and the Go Team and Delve Team do work 
>>>>>>> together to
>>>>>>> give us a better debugging experience. But sometimes the problems that 
>>>>>>> need
>>>>>>> to be fixed are just too hard to do so quickly.
>>>>>>
>>>>>> --
>>>>>> 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/UY6pvL8qeIw/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, 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 a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/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.
>>
> --
Kind Regards,

S. Mantziaris

-- 
You received this message because you are subscribed to the Google 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: [Request] Official golang debugger

[Sotirios Mantziaris]

would it not make sense them to keep dep out of the std toolchain to adapt 
faster to changes?

On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote:
>
> If you reported an issue today, Nov 6, you could be waiting nearly 9 
> months to see a fix in the next released version of Go.
>
> A project living outside the standard library has little going against it 
> other than you have to compile it yourself.
>
> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote:
>>
>> I do not know if the times you mentioned are indeed that long.
>> If it is true then you actually have a good argument.
>>
>> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote:
>>>
>>> I hope not. Anything that ends up in the toolchain is slow to change and 
>>> adapt to user needs. If I have a problem with delve today, I can post an 
>>> issue, fix it and get the next version of delve az quick as a few hours. If 
>>> it would be in the toolchain it could take up to six months to get it 
>>> released. 
>>>
>>> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, <smant...@gmail.com> 
>>> wrote:
>>>
>>>> Yes i know that, but i wonder if it is time to fully integrate delve in 
>>>> the go toolchain and ship it with every release like dep, which exists in 
>>>> another repository, but will be fullly integrated into the toolchain and 
>>>> the releases in some future version.
>>>>
>>>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:
>>>>>
>>>>> Delve is the one towards which the community rally since gdb, still, 
>>>>> doesn't play nice with goroutines. So, for all intents and purposes, 
>>>>> delve 
>>>>> is the official debugger and the Go Team and Delve Team do work together 
>>>>> to 
>>>>> give us a better debugging experience. But sometimes the problems that 
>>>>> need 
>>>>> to be fixed are just too hard to do so quickly. 
>>>>
>>>> -- 
>>>> 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/UY6pvL8qeIw/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to 
>>>> golang-nuts...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>

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

Re: [go-nuts] Re: [Request] Official golang debugger

[Sotirios Mantziaris]

I do not know if the times you mentioned are indeed that long.
If it is true then you actually have a good argument.

On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote:
>
> I hope not. Anything that ends up in the toolchain is slow to change and 
> adapt to user needs. If I have a problem with delve today, I can post an 
> issue, fix it and get the next version of delve az quick as a few hours. If 
> it would be in the toolchain it could take up to six months to get it 
> released. 
>
> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, <smant...@gmail.com 
> > wrote:
>
>> Yes i know that, but i wonder if it is time to fully integrate delve in 
>> the go toolchain and ship it with every release like dep, which exists in 
>> another repository, but will be fullly integrated into the toolchain and 
>> the releases in some future version.
>>
>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:
>>>
>>> Delve is the one towards which the community rally since gdb, still, 
>>> doesn't play nice with goroutines. So, for all intents and purposes, delve 
>>> is the official debugger and the Go Team and Delve Team do work together to 
>>> give us a better debugging experience. But sometimes the problems that need 
>>> to be fixed are just too hard to do so quickly. 
>>
>> -- 
>> 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/UY6pvL8qeIw/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.

[go-nuts] Re: [Request] Official golang debugger

[Sotirios Mantziaris]

Yes i know that, but i wonder if it is time to fully integrate delve in the 
go toolchain and ship it with every release like dep, which exists in 
another repository, but will be fullly integrated into the toolchain and 
the releases in some future version.

On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan wrote:
>
> Delve is the one towards which the community rally since gdb, still, 
> doesn't play nice with goroutines. So, for all intents and purposes, delve 
> is the official debugger and the Go Team and Delve Team do work together to 
> give us a better debugging experience. But sometimes the problems that need 
> to be fixed are just too hard to do so quickly. 

-- 
You received this message because you are subscribed to the Google 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] [Request] Official golang debugger

[Sotirios Mantziaris]

Hi,

with the lack of a official debugger, i  am using delve.
It is very nice and get the work done mostly, needs little or a lot of 
polishing.
Is there any plan to provide a official debugger which will be distributed 
with the releases?
Maybe delve could make it as the official one?

Do not get me wrong, delve is fantastic. Kudos to @derekparker and the 
contibutors for delve .

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

[go-nuts] Re: go on Windows 10 from the bash shell (and the cmd shell)

[Sotirios Mantziaris]

follow the procedure of installing go in linux.
set the following in .bashrc of your home directory at the end:

export PATH=$PATH:/usr/local/go/bin
export PATH=$PATH:$GOPATH/bin

worked for me just fine!

On Wednesday, October 11, 2017 at 8:04:28 AM UTC+3, Pat Farrell wrote:
>
> I've installed the go 1.9 binary distribution on my windows 10 laptop. 
> I just let the install do the defaults. (in addition to learning go, I'm 
> trying to see if I can live with 
> bash under Windows, or if I have to reboot to a linux distro to avoid 
> going crazy, that is a separate topic)
>
> in the cmd shell
> 'go build' works, but creates a file go.exe that when run, displays hello 
> world
> it does not create the expected hello.exe
>
> in the bash shell, 'go build' does not work, it whines that 'go' is not a 
> program
>
> The program 'go' is currently not installed. You can install it by typing:
> sudo apt-get install gccgo-go
>
>
>
> but 'go.exe build' does create a local go.exe which executes and displays 
> the expected hello world.
>
> Which raises a couple of questions:
>
> 1) is the standard documentation wrong/out of date?
> 2) how do I get the go build process to create a hello.exe rather than 
> go.exe?
> 3) how do I get the bash shell to let me just type 'go build' like we all 
> want?
>
>
>
>

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

[go-nuts] Re: go get exits command line in windos

[Sotirios Mantziaris]

i think i figured it out:

git is in the latest version 2.14.2
i downgraded git to 2.14.1.windows.1 and voila all things work again.

On Sunday, October 1, 2017 at 3:39:26 PM UTC+3, Sotirios Mantziaris wrote:
>
> the log is the following:
>
> cd .
> git clone https://github.com/mantzas/adaptlog D:\dev\goprojects\src\
> github.com\mantzas\adaptlog
> cd D:\dev\goprojects\src\github.com\mantzas\adaptlog
> git submodule update --init --recursive
> cd D:\dev\goprojects\src\github.com\mantzas\adaptlog
> git show-ref
> cd D:\dev\goprojects\src\github.com\mantzas\adaptlog
> git submodule update --init --recursive
>
> the repo gets cloned BTW
>
> On Sunday, October 1, 2017 at 3:33:33 PM UTC+3, Dave Cheney wrote:
>>
>> try go get -x
>>
>> On Sunday, 1 October 2017 23:33:04 UTC+11, Sotirios Mantziaris wrote:
>>>
>>> git is available on my path
>>> windows defender (av) is disabled
>>> check out the attached gif.
>>>
>>> this was a fresh windows 10 install
>>> all component (go, git) have been installed with chocolatey.
>>> BTW: mingw works fine.
>>>
>>> can i enable some logs of go get to see what is happening?
>>>
>>> On Sunday, October 1, 2017 at 11:54:43 AM UTC+3, Dave Cheney wrote:
>>>>
>>>> Av, anti virus, software. 
>>>
>>>

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

[go-nuts] Re: go get exits command line in windos

[Sotirios Mantziaris]

the log is the following:

cd .
git clone https://github.com/mantzas/adaptlog 
D:\dev\goprojects\src\github.com\mantzas\adaptlog
cd D:\dev\goprojects\src\github.com\mantzas\adaptlog
git submodule update --init --recursive
cd D:\dev\goprojects\src\github.com\mantzas\adaptlog
git show-ref
cd D:\dev\goprojects\src\github.com\mantzas\adaptlog
git submodule update --init --recursive

the repo gets cloned BTW

On Sunday, October 1, 2017 at 3:33:33 PM UTC+3, Dave Cheney wrote:
>
> try go get -x
>
> On Sunday, 1 October 2017 23:33:04 UTC+11, Sotirios Mantziaris wrote:
>>
>> git is available on my path
>> windows defender (av) is disabled
>> check out the attached gif.
>>
>> this was a fresh windows 10 install
>> all component (go, git) have been installed with chocolatey.
>> BTW: mingw works fine.
>>
>> can i enable some logs of go get to see what is happening?
>>
>> On Sunday, October 1, 2017 at 11:54:43 AM UTC+3, Dave Cheney wrote:
>>>
>>> Av, anti virus, software. 
>>
>>

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

[go-nuts] Re: go get exits command line in windos

[Sotirios Mantziaris]

<https://lh3.googleusercontent.com/-pF5voOGOZEU/WdDgtWj1RwI/BU0/heTuNpdorRM2pRBbVeOwLqgoJS-jQsPHwCLcBGAs/s1600/go_get_crash.gif>


On Sunday, October 1, 2017 at 3:33:04 PM UTC+3, Sotirios Mantziaris wrote:
>
> git is available on my path
> windows defender (av) is disabled
> check out the attached gif.
>
> this was a fresh windows 10 install
> all component (go, git) have been installed with chocolatey.
> BTW: mingw works fine.
>
> can i enable some logs of go get to see what is happening?
>
> On Sunday, October 1, 2017 at 11:54:43 AM UTC+3, Dave Cheney wrote:
>>
>> Av, anti virus, software. 
>
>

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

[go-nuts] Re: go get exits command line in windos

[Sotirios Mantziaris]

git is available on my path
windows defender (av) is disabled
check out the attached gif.

this was a fresh windows 10 install
all component (go, git) have been installed with chocolatey.
BTW: mingw works fine.

can i enable some logs of go get to see what is happening?

On Sunday, October 1, 2017 at 11:54:43 AM UTC+3, Dave Cheney wrote:
>
> Av, anti virus, software. 

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

[go-nuts] go get exits command line in windos

[Sotirios Mantziaris]

Hi,

after a re-installation of windows 10 where go get was working fine it does 
not work now.
Every go command works fine except for go get which terminates the command 
line.
Any ideas?

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

[go-nuts] Re: Golang, Google App Engine, Windows 10

[Sotirios Mantziaris]

Hi,

i am a happy long time user of windows.
i am developing go the last two years and can do almost the same things as 
in Linux.
Visual Studio Code with the  go plugin is fantastic with debugging support 
using delve.
If you want to compile for Linux you can do it from windows with "GOOS=linux 
GOARCH=amd64 go build your code".
I do not use GCE but they have a CLI for windows.

Is there something you need to do that you cannot do in windows?


On Thursday, September 21, 2017 at 12:31:04 AM UTC+3, Rob Shelby wrote:
>
> Hi all.
>
> I'm having to make 2 transitions in my coding life. 
>
> From PHP to Go, which I'm happy about.
>
> From Linux desktop to Windows 10, which I'm not as happy about.
>
> I love using Google's App Engine so I don't need to worry about servers 
> etc. (Not Compute Engine)
>
> Anyways, any steps, advice, etc to easily code in Go and deploy to GAE.
>
> So far, I've figured that installing and running Go in Bash On Linux, but 
> coding in an IDE in Windows, is the easiest. Then deploy from Bash On 
> Windows.
>
> Does anyone else have a better way?
>
> 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.

[go-nuts] Hosting go code in Visual Studio Team Services

[Sotirios Mantziaris]

Hi,

has someone successfully used visual studio team services in a go project 
with support of the go tooling (go get, glide-dep etc)?

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.

Re: [go-nuts] [Proposal] Std Lib Logging Abstraction

[Sotirios Mantziaris]

i have already build such an abstraction myself 
(https://github.com/mantzas/adaptlog).
the issue is not what i use but what all the packages out there use that i 
import.
checkout the link mentioned by Dave Cheney

On Monday, February 13, 2017 at 4:18:58 PM UTC+2, Tamás Gulácsi wrote:
>
> Use an adapter which provides a writer to std lib's log, and pipes it 
> through your chosen logging lib.
> Like go-kit/kit/log.StdAdapter.

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

Re: [go-nuts] [Proposal] Std Lib Logging Abstraction

[Sotirios Mantziaris]

nice, i'll take a look

On Monday, February 13, 2017 at 10:00:15 AM UTC+2, Dave Cheney wrote:
>
> There is an active discussion thread over on the development list -> 
> https://groups.google.com/forum/#!topic/golang-dev/F3l9Iz1JX4g

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

Re: [go-nuts] [Proposal] Std Lib Logging Abstraction

[Sotirios Mantziaris]

let's assume you use a package that logs with std "log" package and my app 
uses something else let's say logrus.
What would the logging result be? Would it not be inconsistent?

On Monday, February 13, 2017 at 9:47:46 AM UTC+2, Jan Mercl wrote:
>
> On Mon, Feb 13, 2017 at 8:44 AM Sotirios Mantziaris <smant...@gmail.com 
> > wrote:
>
>  > ... which prohibit me of using anything else if i want to have a 
> consistent logging experience.
>
> What does "consistent logging experience" mean?
>
> -- 
>
> -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.

[go-nuts] [Proposal] Std Lib Logging Abstraction

[Sotirios Mantziaris]

Hi, 

i was wondering if the std lib should implement a logging abstraction so 
that every lib developer can abstract away logging and let the final lib 
user provide the implementation it needs.
The reason for this is that like everybody else i use a lot of open source 
and many of them use std "log" package(some may us other which is worse) 
which prohibit me of using anything else if i want to have a consistent 
logging experience.

-- 
You received this message because you are subscribed to the Google 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] private repository .git and import paths

[Sotirios Mantziaris]

Hi,

my problem is a follows. The repo lives in the following git repo 
http://some/app.git

when i go get the repo the folder structure mimics the URL so i end up with 
a local folder app.git.
As a result go install generates a binary named app.git instead of plain 
app.
All imports look like this some/app.git/model.

This runs on a ci server too which is another pain point.

How do you handle this except from creating a repo with the name app and 
not app.git?
Any thoughts?

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

[go-nuts] Re: .net core vs go

[Sotirios Mantziaris]

I am currently moving one of my applications to .net core. Currently i use
Redis for caching, PostgreSQL and Nginx. All run in Linux except my Rest
Service which runs in Windows.
After the move to asp.net core i will host the application in Linux,
probably docker. Could you point me to the one place where Microsoft will
make money out of this?

My point is that you assume that every .net developer use by default Sql
Server, IIS etc but that is simply not true.

Check out the https://www.techempower.com/benchmarks/. This has nothing to
do with admitting it or not. check some facts.
Check out
http://web.ageofascent.com/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/
 which is a implementation of a MMO Game which run on asp.net core and
windows server 2016 nano.

I know it will not make any difference to you so i will conclude the debate
as pointed out by Dave Cheney.
Thanks

On Wed, Nov 16, 2016 at 10:51 PM Golden Ratio <0xc...@gmail.com> wrote:

> I think you are being naive. You don't pay in terms of running the code
> per-se, but to get other parts of their toolchain that generally go
> together with the whole baggage, e.g. MSSQL, OS, support, updates, etc.
> That's the whole point.
>
> This would take the conversation in another direction and then you'll
> complain again. The point here is that the .Net stack is still very slow,
> whether you admit or not because I have seen it a million times ;)
>
-- 
Kind Regards,

S. Mantziaris

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

[go-nuts] Re: .net core vs go

[Sotirios Mantziaris]

   - I did not mention windows at all... so what's with that???
   - And about the profit? they allow you to run your code on Linux and MS
   does not get a dime? The point is that you can develop .net core and don't
   pay anything to MS.
   - Yes VS Code is based on Github's electron framework, which is used by
   many others which may not contribute either.
   - Electron is also based on node, chromium, v8 etc...

I think we should stay on topic which is .net core vs go and contribute to
the discussion.


On Wed, Nov 16, 2016 at 9:00 PM Golden Ratio <0xc...@gmail.com> wrote:

> So basically what you are saying is that we need another OSS tool to fix
> sluggishness in current Microsoft toolchain?
>
> No, thank you :) The next generation app developers would just like to
> avoid the sluggish part and the slow operating system altogether :)
>
> Well, we all know why Microsoft is all of a sudden in OSS frenzy. They
> want to profit from it. Not that anything is wrong with it, but this is
> their only goal.
>
> Best stuff around and you refer to VS Code? They just copied the core
> parts from Atom's Electron without contributing anything back.
>
>
> On Wed, Nov 16, 2016 at 11:00 PM, Sotirios Mantziaris <
> smantzia...@gmail.com> wrote:
>
> I do not agree with the above. Let me explain:
>
>- First of all asp.net core and it's new web server kestrel should be
>used behind nginx or similar. Hiding it behind IIS is slow because of IIS
>and not because of kestrel. Check out the new
>https://www.techempower.com/benchmarks... which show not the best, but
>not the worst either... No 10 in the plaintext category is pretty good if
>you ask me...
>- I don't even know to what you mean by saying single core. Are you
>referring to .net? IIS?
>- The people that once called OSS community communists are not in
>charge anymore...  It's like saying that German's are by default bad
>because of you know who i mean...
>- First Microsoft is closed source, evil corp etc and people where
>angry... Then MS goes almost full blown open source embraces almost
>everything and still people are angry... Conclusion, people are angry
>anyways.
>- Not every .Net Developer use only the MS toolchain, and with core
>you can use anything a go/java/ruby developer uses...
>
> My personal note is the following:
> MS does not have the best stuff around... but they have a pretty good
> understanding of creating good developer tools and boost productivity
> If you have used Visual Studio and Sql Server Management Studio then you
> know what i mean.
>
> This is where, for my taste, go has a lot to learn ... and BTW i use
> Visual Studio Code for my go development with delve as debugger. The next
> Visual Studio will support go natively...
>
> Things are getting way better for us devs and this is a win-win situation.
>
>
> On Wednesday, November 16, 2016 at 5:06:57 PM UTC+2, 0xc...@gmail.com
> wrote:
>
> I have been managing Windows based environments for well over a decade and
> .Net is one of the most slowest stacks I have ever seen.
> That being said, I just finished configuring ASP.net Core Module on IIS
> (it's just been released) for a client and it's still dog slow
> (particularly the app startup in IIS).
>
> Not to mention the single core limitation.
>
> Microsoft has been recently seen jumping into OSS bandwagon by releasing
> VS Code, the .Net Core, Powershell for Linux and native Linux containers
> for Windows. Seems like they are desperate to get into this market, which
> they had been blatantly ignoring for many years!
>
> Looking at "Fast" description at
> https://www.microsoft.com/net/core/platform, I can see how Microsoft is
> concocting lies to up-sell their product. These are same people who once
> accused OSS community as communists ;)
>
> Like Henry said, Microsoft toolchain is only good if you are stuck with
> its existing investment, just like StackOverflow etc.
>
> To me, it's all the baggage that comes with the stuff they keep renaming
> and reinventing
> <https://web.archive.org/web/20160120002529/http://www.hanselman.com/blog/ASPNET5IsDeadIntroducingASPNETCore10AndNETCore10.aspx>
> .
>
>
> On Monday, October 10, 2016 at 5:59:31 AM UTC+5, Henry wrote:
>
> Go is a relatively small language, so it should be easy to learn
> especially if you are already familiar with other programming languages.
> Go's binary generation is also pretty good and it gets better with each
> release.
>
> The major hurdle of a .net shop switching to other platform/language is
> usually the non-technical ones. A typical .net shop usually have a
> significant investment in .net and the tools arou

[go-nuts] Re: .net core vs go

[Sotirios Mantziaris]

I do not agree with the above. Let me explain:

   - First of all asp.net core and it's new web server kestrel should be 
   used behind nginx or similar. Hiding it behind IIS is slow because of IIS 
   and not because of kestrel. Check out the 
   new https://www.techempower.com/benchmarks... which show not the best, but 
   not the worst either... No 10 in the plaintext category is pretty good if 
   you ask me...
   - I don't even know to what you mean by saying single core. Are you 
   referring to .net? IIS?
   - The people that once called OSS community communists are not in charge 
   anymore...  It's like saying that German's are by default bad because of 
   you know who i mean...
   - First Microsoft is closed source, evil corp etc and people where 
   angry... Then MS goes almost full blown open source embraces almost 
   everything and still people are angry... Conclusion, people are angry 
   anyways.
   - Not every .Net Developer use only the MS toolchain, and with core you 
   can use anything a go/java/ruby developer uses... 

My personal note is the following: 
MS does not have the best stuff around... but they have a pretty good 
understanding of creating good developer tools and boost productivity
If you have used Visual Studio and Sql Server Management Studio then you 
know what i mean.

This is where, for my taste, go has a lot to learn ... and BTW i use Visual 
Studio Code for my go development with delve as debugger. The next Visual 
Studio will support go natively...

Things are getting way better for us devs and this is a win-win situation.


On Wednesday, November 16, 2016 at 5:06:57 PM UTC+2, 0xc...@gmail.com wrote:
>
> I have been managing Windows based environments for well over a decade and 
> .Net is one of the most slowest stacks I have ever seen.
> That being said, I just finished configuring ASP.net Core Module on IIS 
> (it's just been released) for a client and it's still dog slow 
> (particularly the app startup in IIS).
>
> Not to mention the single core limitation.
>
> Microsoft has been recently seen jumping into OSS bandwagon by releasing 
> VS Code, the .Net Core, Powershell for Linux and native Linux containers 
> for Windows. Seems like they are desperate to get into this market, which 
> they had been blatantly ignoring for many years!
>
> Looking at "Fast" description at 
> https://www.microsoft.com/net/core/platform, I can see how Microsoft is 
> concocting lies to up-sell their product. These are same people who once 
> accused OSS community as communists ;)
>
> Like Henry said, Microsoft toolchain is only good if you are stuck with 
> its existing investment, just like StackOverflow etc.
>
> To me, it's all the baggage that comes with the stuff they keep renaming 
> and reinventing 
> 
> .
>
>
> On Monday, October 10, 2016 at 5:59:31 AM UTC+5, Henry wrote:
>>
>> Go is a relatively small language, so it should be easy to learn 
>> especially if you are already familiar with other programming languages. 
>> Go's binary generation is also pretty good and it gets better with each 
>> release. 
>>
>> The major hurdle of a .net shop switching to other platform/language is 
>> usually the non-technical ones. A typical .net shop usually have a 
>> significant investment in .net and the tools around it. Moving to another 
>> language (eg. Go) often means throwing away those existing investment. 
>>
>

-- 
You received this message because you are subscribed to the Google 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: .net core vs go

[Sotirios Mantziaris]

You are correct about the concurrency, no hard feeling. thank god this was 
no tech interview! ;)

BTW i just found this 
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore=go
It looks like .net core seems to be comparable to go (and better in some 
cases). And it is only preview 2!

My general feeling .net core which is not statically linked can hold its 
ground very well!
This was unexpected for .net and unfortunate for go (which will get better 
with their improvements in GC etc). 

On Sunday, October 9, 2016 at 1:27:14 PM UTC+3, ohir wrote:
>
> Dnia 2016-10-09, o godz. 02:06:01 
> Sotirios Mantziaris <smant...@gmail.com > napisał(a): 
>
> Excuse me for a bit of 'ad personam' tone, it is not meant to be mean. 
>
> > And i was comparing the concurrency framework 
> You did not though. 
>
> > with all the bells and whistles 
> But your code used none. [e.g. custom data passed to .net task] 
>
> Your present microbenchmark code at most compares malloc and printf 
> implementations (and .net optimizers). In fact it is not even 
> concurrent: https://blog.golang.org/concurrency-is-not-parallelism. 
>
> In simplest words: concurrency is all about doing usable things in 
> one task while other one awaits for some (slow) things to happen. 
> The pseudo-parallelism is just a byproduct. 
>
> If you really want to compare _speed_ of the products of two compilers 
> you need to compile the same code with both. It is easy. 
>
> But if you really want to compare _speed_ of the products of two compilers 
> of different PLs you need to implement the same heavy concurrency in both 
> PL. 
> This is not that simple goal. Sometimes it even is not achievable (ie. 
> in comparing java vs. erlang). 
>
> > From what i understand goroutines are not threads either. There is a 
> > manager that handles which one runs on which thread, just like the 
> > implementation of .net. 
>
> Unlike .net Task every goroutine is given its own stack from the creation 
> time. So it is prepared to do some real work just in time it will execute. 
>
> DotNet, by specification, may even use a single task instance: "The number 
> of Task instances that are created behind the scenes by Invoke is not 
> necessarily equal to the number of delegates that are provided. The TPL 
> may 
> employ various optimizations, especially with large numbers of delegates." 
> [https://msdn.microsoft.com/en-us/library/dd537609(v=vs.110).aspx] 
>
> If you still want to compare PLs, do reimplement some (heavily concurrent) 
> real solution avaliable in golang ecosystem in C# (you do know intimately) 
> Then you might compare both in production. 
>
> -- 
> 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.

Re: [go-nuts] Re: .net core vs go

[Sotirios Mantziaris]

You are adding the hash calculation to the mix which skew the results, but
the end result is the same.

On Sun, Oct 9, 2016, 13:05 Jan Mercl <0xj...@gmail.com> wrote:

>
> On Sun, Oct 9, 2016 at 11:47 AM Sokolov Yura 
> wrote:
>
> > .Net still faster and uses less memory. But not dramatically faster. But
> dramatically less memory.
> It is pitty.
>
> The code is not making a reasonable comparison because it creates N
> goroutines. It should create only GOMAXPROCS goroutines and use no channels
> and use no WaitGroup. Then it would be roughly equal to what .net does.
>
> But we are already far away from what was my point. Nevermind ;-)
>
> --
>
> -j
>
> --
> 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/_6K8SpMFsTM/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.
>
-- 
Kind Regards,

S. Mantziaris

-- 
You received this message because you are subscribed to the Google 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: .net core vs go

[Sotirios Mantziaris]

I am waiting for the final implementation to check them out. Looks
promising.

On Sun, Oct 9, 2016, 12:15 Jan Mercl <0xj...@gmail.com> wrote:

> On Sun, Oct 9, 2016 at 11:06 AM Sotirios Mantziaris <smantzia...@gmail.com>
> wrote:
>
> > From what i understand goroutines are not threads either.
>
> That's the whole point for the original claim. there's not way .net could
> ever cope with 100k threads. If you want to compare apples to apples, the
> Go version should run only about GOMAXPROCS goroutines. Also, be sure to
> make some real work in the goroutine and collect and output its results
> (sum for example) to avoid optimizing it away.
>
> Anyway, then the comparison would become that of picking a random task to
> run on a thread vs a full blown goroutine scheduler with the complete
> ready/running/wating state handling.
>
> BTW: How are .net channels doing? ;-)
>
> --
>
> -j
>
-- 
Kind Regards,

S. Mantziaris

-- 
You received this message because you are subscribed to the Google 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: .net core vs go

[Sotirios Mantziaris]

Since i don't know if "dotnet run" does optimize code, you may got a point 
there. changed the code to return a string from the function and use 
Task. 
Result:
dotnet run 100
Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping 
compilation.
Task to execute: 100
Task 961 done!
100 in 00:00:01.1604266

Still much faster than go!

On Sunday, October 9, 2016 at 10:53:54 AM UTC+3, ohir wrote:
>
> Dnia 2016-10-08, o godz. 23:55:08 
> Sotirios Mantziaris <smant...@gmail.com > napisał(a): 
>
> > Please review my code for any mistakes i made and let me know. 
>
> >private static void Work(int i){ 
> >var t = string.Format("Task {0} done!", i); 
> >} 
>
> Above construct is a NOOP and almost certainly did not went to executable. 
>   
> Probaly even your 'for (int i = 0; i < tasks.Length; i++)' block had been 
> optimized away, as there is no work to do as seen by compiler. 
>
> So in .net version you measure only the tasks array allocation/init time: 
>
> > var sw = Stopwatch.StartNew(); 
> > var tasks = new Task[taskCount]; 
> > sw.Stop(); 
>
> In an era of multicore and aggresive optimizers microbenchmarking is moot. 
>
> -- 
> 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.

Re: [go-nuts] Re: .net core vs go

[Sotirios Mantziaris]

Hi Jan. The correct analogy here are not threads but Tasks from the 
excellent Task Parallel Library in order to compare Apples with Apples. 

i have a little stupid source code (https://github.com/mantzas/headon) that 
run in parallel n tasks and the equivalent in go.

dotnet run 100
Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping 
compilation.
Task to execute: 100
100 in 00:00:00.8903075
 
go.exe -tasks 100
Task to execute: 100
100 in 3.9731993s

when running higher number of tasks like 1000 i get:

λ dotnet run 1000
Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping 
compilation.
Task to execute: 1000
1000 in 00:00:07.9395814

the same in go had the following result:
eating all my memory and crashed

BTW the dotnet memory consumption is around 700 MB. 
When using dotnet's Parallel.For we have even better results

λ dotnet run 1000
Project dotnet (.NETCoreApp,Version=v1.0) was previously compiled. Skipping 
compilation.
Task to execute: 1000
1000 in 00:00:00.8419129

and the memory consumption is around 7MB!!!

i have tested the same in Linux so i could say the following based on the 
above:

dotnet has a better implemented concurrency library allowing only some 
tasks to run concurrently (POOL) and it is by a lot faster than goroutines.

in go you can shoot yourself in the foot easily.

Please review my code for any mistakes i made and let me know.




On Saturday, October 8, 2016 at 10:33:24 AM UTC+3, Jan Mercl wrote:
>
> On Wed, May 18, 2016 at 4:06 PM Sotirios Mantziaris <smant...@gmail.com 
> > wrote:
>
> > The claim that .Net is not heavily concurrent is not true either. 
>
> A Go program executing 100k goroutines needs 200MB or 400MB RAM for stack, 
> depending on version, so it can run just fine. A .net program trying to 
> execute 100k threads will OOM way before reaching a even a small fraction 
> of the goal.
>
> -- 
>
> -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] Re: .net core vs go

[Sotirios Mantziaris]

Hi,

i too use go and i see all the benefits that you are mentioning. I was only 
pointing out what was wrong in the post about windows...

BTW You don't need IIS to run .Net Core. There is a new web server named 
Kestrel (check this video https://vimeo.com/172009499) which performs very 
well.
So creating docker containers is straightforward too. You just need more 
files to deploy instead of one and if you automated this it should not 
matter!

BTW There is a project research named .Net Native which will eventually 
create on static linked binary!!!

I do not have any idea about memory consumption on .net core., this would 
be nice to check out! Comparing ruby with go is a little off, since ruby is 
not known to be performant and cheap on memory.

Creating apps with both is very nice. go gives you what you have mentioned. 
.net core almost the same with better tooling (Visual Studio rocks)

On Saturday, October 8, 2016 at 9:25:27 AM UTC+3, francoi...@gmail.com 
wrote:
>
> Hi Sotirios
>
> I have always been someone trying to balance out the "developer 
> productivity" vs "runtime efficiency". By only using a coding 
> language/framework because you can code much quicker in it is almost 99% of 
> the time going to bite you in the *** later. Sure if you just want to 
> "prototype" something it doesn't matter. But how often does the prototype 
> not become the starting point and turn into the "legacy" black-box nobody 
> want to touch.
>
> Consider for instance something like Gitlab written in Ruby vs Gogs (with 
> Drone CI) both written in golang.
>
> Gitlab requires about 2GB Memory (minimum) to run in production with as 
> little as 10 users. If you have less than that Gitlab will feel really, 
> really slow and even sometimes run into "out of memory" errors.
>
> Now Gogs on the other side uses about 20MB of memory. Sure, Gitlab is at 
> this point more mature than Gogs but is it sustainable? Consider having to 
> host these two on DigitalOcean for example. You will need at least the 2GB 
> Droplet for Gitlab whereas the 512MB Droplet will be more than sufficient 
> for Gogs. You can even turn it up a notch. If you want to host 20 instances 
> of Gitlab or Gogs. For Gitlab you will need 20 of the 2GB Droplets, adding 
> up to $400/month. But for gogs the SINGLE 512MB will still be sufficient at 
> $5/month.
>
> Now that is enough on the Memory side. Golang can be built as a "static 
> binary" which means the SINGLE binary file contains everything about the 
> the application. Consider this article: 
> https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/,
>  
> where the static linked binary is a mere 5.6MB in size. If you take .NET 
> you will probably need IIS and the .NET Framework on top of your 
> application.
>
> Golang also actually include the http server in this 5.6MB of static 
> binary. So no need for another layer like IIS.
>
> Just a handy tip. There are "awesome lists" of about any framework and 
> language out there:
>
>- Curated list of them all: https://github.com/sindresorhus/awesome
>- Golang: https://github.com/avelino/awesome-go and 
>https://github.com/golang/go/wiki/Projects 
>- .NET Core: https://github.com/thangchung/awesome-dotnet-core
>
>
>
>
> On Wednesday, 18 May 2016 16:06:30 UTC+2, Sotirios Mantziaris wrote:
>>
>> Dear Tim,
>>
>> We are a .Net house and we are running "windows services" for months 
>> without having any problem. Sql Server, which is a very robust RDBMS, is a 
>> windows service and runs rock solid for years. So the issues you mentioned 
>> are mainly your own code issues.
>>
>> Windows has a feature called Task Scheduler where you can schedule 
>> anything to run on a schedule if that is what you want.
>>
>> The claim that .Net is not heavily concurrent is not true either. You can 
>> use TPL (Task Parallel Library) and run a really solid and performant 
>> concurrent programming model with ease. 
>> This will scale very nicely with the cores of your machine. Especially 
>> when using Parallel.For which does some optimizations.
>>
>> Long story short. Please try to be correct on your claims since you are 
>> sounding like you don't know windows and .net that much. no harm intended. 
>>
>> Kind regards
>>
>> On Wednesday, May 18, 2016 at 5:09:13 AM UTC+3, Tim Hawkins wrote:
>>>
>>> He mentions that they have a bunch of Web scrappers,  this kind of task 
>>> is heavily concurrent, something that .net is not know for, but golang is. 
>>> We are a php house, but we are switching to go for this one reason, ou