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

[Jan Mercl]

On Fri, Mar 9, 2018 at 8:19 AM Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> wrote:

> So if this is a "just" a mutex, this whole thing will not be atomic - it
would introduce intermediate (albeit invisible) between "<-" parts. I was
hoping for the "edge collapse" here.

Not sure IIUC, but I should have probably emphasized that the "atomicity"
can be seen over the single send or receive _operation_ only. Within a send
or receive _statement_ the situation is more complex. For instance, in 'ch
<- f()', the RHS is evaluated before the send operation is even attempted.
The send operation may block giving another goroutine a chance, for
example, to call f() again and send to 'ch' before the first caller of
'f()' gets unblocked.

Considering

r := make(chan int, 100)
w := make(chan int, 100)

go func() {
i := 0
for {
ch <- i
i++
}
}

go func() {
for {
w <- <-r
}
}


go func() {
for {
w <- <-r
}
}

We cannot rely on values pulled later from 'w' will to be in order even
though values put into 'r' are guaranteed to be such.

-- 

-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] Is channel push atomic?

[Andrey Tcherepanov]

Thanks Jan,

So if this is a "just" a mutex, this whole thing will not be atomic - it 
would introduce intermediate (albeit invisible) between "<-" parts. I was 
hoping for the "edge collapse" here.

Andrey


On Friday, March 9, 2018 at 12:08:13 AM UTC-7, Jan Mercl wrote:
>
> On Fri, Mar 9, 2018 at 7:47 AM Andrey Tcherepanov <
> xnow4f...@sneakemail.com > wrote:
>
> > ch <- <-ch // Is this an atomic operation?
>
> Channel send and receive operations are safe wrt to concurrency. That may 
> be seen atomic in a certain sense: only one goroutine at a time can ever 
> perform such operation on a given channel without having to coordinate with 
> any other goroutine - because internally the operation is guarded by a 
> mutex.
>
> -- 
>
> -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] Is channel push atomic?

[Jan Mercl]

On Fri, Mar 9, 2018 at 7:47 AM Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> wrote:

> ch <- <-ch // Is this an atomic operation?

Channel send and receive operations are safe wrt to concurrency. That may
be seen atomic in a certain sense: only one goroutine at a time can ever
perform such operation on a given channel without having to coordinate with
any other goroutine - because internally the operation is guarded by a
mutex.

-- 

-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] 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] Is channel push atomic?

[Henrik Johansson]

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

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

> Hello fellow nuts,
>
> Is pull-push to a (same) channel atomic?
>
> func f() {
>ch := make(chan interface{}, 100)
>
>// ...
>
>ch <- <-ch // Is this an atomic operation?
> }
>
>
> Thank you very much!
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Is channel push atomic?

[Andrey Tcherepanov]

Hello fellow nuts,

Is pull-push to a (same) channel atomic?

func f() {
   ch := make(chan interface{}, 100)

   // ... 

   ch <- <-ch // Is this an atomic operation?
}


Thank you very much!


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

[go-nuts] Re: how to force tests to run on main C thread?

[Jason E. Aten]

Appears that TestMain() was added for this situation:

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

http://cs-guy.com/blog/2015/01/test-main/

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

[go-nuts] Re: how to force tests to run on main C thread?

[Jason E. Aten]

Ah, I found this question was asked by Gustavo Niemeyer back in 2014... 
Quoting from the last post of

https://groups.google.com/forum/#!topic/golang-dev/YPjaFoesQzU

> rsc
> You can't move test execution onto the main goroutine. t.FailNow uses 
runtime.Goexit.

I wonder if there's been any change that would enable this?  I'm using a C 
library that
I suspect is sensitive to being tested on the main thread, and I would like 
to test that
assumption.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] how to force tests to run on main C thread?

[Jason E. Aten]

I see how to make the main program run on the main C thread, using 
runtime.LockOSThread()

https://groups.google.com/d/msg/golang-nuts/IiWZ2hUuLDA/SNKYYZBelsYJ

But I wonder how to do the same for blah_test.go test code... I need to 
start my tests running on the main C thread.

Thanks!

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: golang tcp transport just like nc

[suconghou]

It works like a charm, thank you very much !



在 2018年3月8日星期四 UTC+8上午11:17:03，苏聪厚写道：
>
>
>
> linux nc command port to golang 
>
>
> in nc , we can do this
>
> echo 'my id is 1' > /tmp/1
> echo 'my id is 3' > /tmp/3
> rm -rf /tmp/2 /tmp/4
>
>
>
> server
>
> nc -l 19090 < /tmp/1 > /tmp/2
>
> ( if you are in linux not mac this may be  ` nc -l -p 19090 `  )
>
> client
>
>
> nc 127.0.0.1 19090 < /tmp/3 > /tmp/4
>
>
> when finish ,both server and client will be closed
>
> client send /tmp/3 is saved by server to /tmp/2
>
> server send /tmp/1 is saved by server to /tmp/4
>
> then use golang do the same thing , but when finished , both server and 
> client can not closed automaticly
>
>
>
> echo 'my id is 1' > /tmp/1
> echo 'my id is 3' > /tmp/3
> rm -rf /tmp/2 /tmp/4
>
>
>
>
>
> ./nc serer < /tmp/1 > /tmp/2
>
>
>
> ./nc  < /tmp/3 > /tmp/4
>
>
>
> please help me how to solve this and works like nc 
>
>
> example code 
>
> https://gist.github.com/suconghou/a1bfab9a30b3408400b6382d73051227
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Get Programming with Go

[Nathan Youngman]

Yup. The "about this book" section in the front matter does suggest that
seasoned C/C++ programmers look elsewhere, though perhaps it could be
written more directly, or maybe in more places? Here's a quote from the
front matter:

"If you are a polyglot programmer who understands the merits of static
typing and composition over inheritance, if pointers and mutexes are second
nature, if optimizing memory allocations and CPU caches are an old hat, you
will find plenty of books and resources that ramp up quickly and cover
advanced topics more thoroughly."

Have you looked at http://www.gopl.io/ ?

Nathan.


On 8 March 2018 at 12:41,  wrote:

>
> On Wednesday, 7 March 2018 10:46:58 UTC-4, Nathan Youngman wrote:
>>
>> Learn about error handling and concurrent state in the latest release of
>> Get Programming with Go, available from Manning Books.
>>
>> The first draft is complete. If you have any feedback, now’s the time to
>> get it in, as we are currently editing the book before it goes to
>> production.
>>
>> https://bit.ly/programminggo
>>
>>
>> I'd recommend specifying your target audience.  That would appear to
> exclude seasoned C/C++ programmers.
>
>
> --
> 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/_-35shjZqUU/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.
>



-- 
Nathan Youngman
Email: he...@nathany.com
Web: https://nathany.com

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

[go-nuts] Re: [Advice needed] How to vendor common dependencies for plugins

[Michael Andersen]

I am interested in this problem too, especially dealing with 
golang.org/x/net/trace which is used by grpc which is used by multiple 
packages I import.

On Wednesday, March 7, 2018 at 10:03:37 PM UTC-8, Jay Guo wrote:
>
> Golang gurus,
>
> I'm currently trying to modularize my project with the help of Golang 
> plugin, and I come across this dependency vendoring dilemma.
>
> Let's say we have a project layout:
>
>- Two different projects in separate repo: `Host` and `Guest`
>- `Host` depends on package `pkgA`
>- `Guest` depends on package `pkgA` too
>- `Guest` is compiled as plugin, and loaded by `Host`
>- `pkgA` is vendored into both `Host` and `Guest`
>
> In this situation, `pkgA` would be loaded twice and independently, meaning 
> there are two instance of the package in the program, one lives in `Guest` 
> and one in `Host`. init() would be called twice as well
>
> Particularly, I'm dealing with golang.org/x/net/trace package, which 
> actually registers an endpoint /debug/requests. The second attempt would 
> panic because of double-registration.
>
> I'd appreciate any advice on how to manage common dependencies of plugin 
> and main project, thank you!
>
> - 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: Debugging unit tests in go

[ralphdoncaster]

On Thursday, 8 March 2018 12:32:42 UTC-4, Parthasarathi Kundu wrote:
>
> Hi,
> How can I debug the unit tests in go ? Normal executible I debug with gdb 
> or delve.
> I am running from command prompt go test -v ./test/... -run Test_Connect.
>
> Any thing better with ide ?
>
> Thanks
>
>
I use delve for unit tests:

$ ~/go/bin/dlv test
Type 'help' for list of commands.
(dlv) b eth_test.go:49
Breakpoint 1 set at 0x5691fb for 
github.com/nerdralph/crypto/sha3.makeCacheFast() ./eth_test.go:49
(dlv) c
> github.com/nerdralph/crypto/sha3.makeCacheFast() ./eth_test.go:49 (hits 
goroutine(1):1 total:1) (PC: 0x5691fb)
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Get Programming with Go

[ralphdoncaster]

On Wednesday, 7 March 2018 10:46:58 UTC-4, Nathan Youngman wrote:
>
> Learn about error handling and concurrent state in the latest release of 
> Get Programming with Go, available from Manning Books.
>
> The first draft is complete. If you have any feedback, now’s the time to 
> get it in, as we are currently editing the book before it goes to 
> production.
>
> https://bit.ly/programminggo
>
>
> I'd recommend specifying your target audience.  That would appear to 
exclude seasoned C/C++ programmers.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: telling apart errors returned by database/sql

[Zach]

The `pq.PGError` class appears to be deprecated and it's now suggested 
to use `pq.Error`. Here's a 
more concrete example of an insert failing due to a constraint violation 
(on conflict clause...) 

if err, ok := err.(*pq.Error); ok && err.Code.Class().Name() == 
"integrity_constraint_violation" {
 ...
}



On Saturday, June 8, 2013 at 3:37:29 PM UTC-4, Jochen Voss wrote:
>
> Dear all,
>
> In a go program, I need to recognise when an insert into a SQL table fails
> because the primary key is already present (as opposed to failing for some
> other reason).  Currently I am checking whether the string value of the
> error returned by the Exec method of sql.DB equals "column ... is not 
> unique".
>
> My questions:
> - Is there a better way of checking for failure due to duplicate keys?
> - Is the error string guaranteed to be independent of the
>   database backend?
>
> Many thanks,
> Jochen
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] glr support in goyacc?

[Jan Mercl]

On Thu, Mar 8, 2018 at 7:44 PM David Wahlstedt <
david.wahlstedt@gmail.com> wrote:

> So, if golang has been bootstrapped, compiled with itself, how did they
write the parser?
> By hand, or by using an LR parser and tweaking the grammar?

Go authors initially used a modified grammar (distilled version at
https://github.com/cznic/gc/blob/b007e32c610fc39d850653c9b09d7515507f2b6e/testdata/parser/parser.y)
in combination with a simple transformation of the input token stream in
the lexer (functionally equivalent Go implementation can be seen also at
https://github.com/cznic/gc/blob/b007e32c610fc39d850653c9b09d7515507f2b6e/all_test.go#L976
).

Nowadays the gc uses a handwritten parser, so the class of the language no
more matters [that much]. (Alternative experimental implementation also at
https://github.com/cznic/gc/blob/b007e32c610fc39d850653c9b09d7515507f2b6e/parser.go
)

IMHO, GLR would be an overkill for a Go parser.



-- 

-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] glr support in goyacc?

[David Wahlstedt]

Hi,
I wonder if there are any plans to add the "glr" option to goyacc (it 
doesn't look as if this is the case) ?

According to this thread,
https://stackoverflow.com/questions/25976394/how-to-resolve-ambiguity-in-the-definition-of-an-lr1-grammar

golang is "not LALR(1), nor LR(k) for any k".

So, if golang has been bootstrapped, compiled with itself, how did they 
write the parser?
By hand, or by using an LR parser and tweaking the grammar?

Then, shouldn't be a good idea for goyacc to have "glr" support, as there 
is in e.g. bison?

Sorry if my question is naive (it is, probably), I am new to golang.

BR,
David

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Are the semicolons rules some weird?

[digg]

On Thursday, March 8, 2018 at 12:36:19 PM UTC-5, Ian Lance Taylor wrote:
>
> On Thu, Mar 8, 2018 at 9:13 AM,  > 
> wrote: 
> > 
> > On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote: 
> >> 
> >> On Thu, Mar 8, 2018 at 8:43 AM,   wrote: 
> >> > 
> >> > There are two semicolon rules in Go spec: 
> >> > https://golang.org/ref/spec#Semicolons 
> >> > The first one states how a semicolon will be automatically inserted, 
> >> > however, the second one states how a semicolon can be omitted. 
> >> > Isn't more consistent to modify the second one to the following 
> >> > description? 
> >> > 
> >> > To allow complex statements to occupy a single line, a semicolon may 
> be 
> >> > inserted before a closing ")" or "}". 
> >> 
> >> We would have to change a lot of the syntax productions.  For example 
> >> 
> >> StructType= "struct" "{" { FieldDecl ";" } "}" . 
> >> 
> >> The rule as stated permits omitting the final ";" when the "}" follows 
> >> on the same line (if the "}" is on a different line, the ";" is 
> >> inserted automatically anyhow).  If we change to your version, we need 
> >> to rewrite the StructType production to not have a trailing ";", and 
> >> then rely on the new rule to permit adding one. 
> >> 
> > 
> > Ok, get it. 
> > 
> > But how about just change the second rule to the following instead. 
> > 
> > To allow complex statements to occupy a single line, a semicolon may be 
> > optional before a closing ")" or "}". 
> > Compilers will insert it back if it is absent. 
>
> I guess I'm not sure why that is any clearer than the current rule. 
>

The benefit of the new one is it is easier to explain the rules for new 
gophers.
With the modified version, we can explain the rules as:

Many semicolons in Go are optional, compilers will insert back the absent 
semicolons for us automatically.
The insertion rules are 1) . 2) .
 



> 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] Are the semicolons rules some weird?

[Ian Lance Taylor]

On Thu, Mar 8, 2018 at 9:14 AM,   wrote:
> btw, are there any cases a semicolon may be omitted before a closing ")"?

var ( a = 1 )

Ian


> On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote:
>>
>> On Thu, Mar 8, 2018 at 8:43 AM,   wrote:
>> >
>> > There are two semicolon rules in Go spec:
>> > https://golang.org/ref/spec#Semicolons
>> > The first one states how a semicolon will be automatically inserted,
>> > however, the second one states how a semicolon can be omitted.
>> > Isn't more consistent to modify the second one to the following
>> > description?
>>>
>> > To allow complex statements to occupy a single line, a semicolon may be
>> > inserted before a closing ")" or "}".
>>
>> We would have to change a lot of the syntax productions.  For example
>>
>> StructType= "struct" "{" { FieldDecl ";" } "}" .
>>
>> The rule as stated permits omitting the final ";" when the "}" follows
>> on the same line (if the "}" is on a different line, the ";" is
>> inserted automatically anyhow).  If we change to your version, we need
>> to rewrite the StructType production to not have a trailing ";", and
>> then rely on the new rule to permit adding one.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Are the semicolons rules some weird?

[Ian Lance Taylor]

On Thu, Mar 8, 2018 at 9:13 AM,   wrote:
>
> On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote:
>>
>> On Thu, Mar 8, 2018 at 8:43 AM,   wrote:
>> >
>> > There are two semicolon rules in Go spec:
>> > https://golang.org/ref/spec#Semicolons
>> > The first one states how a semicolon will be automatically inserted,
>> > however, the second one states how a semicolon can be omitted.
>> > Isn't more consistent to modify the second one to the following
>> > description?
>> >
>> > To allow complex statements to occupy a single line, a semicolon may be
>> > inserted before a closing ")" or "}".
>>
>> We would have to change a lot of the syntax productions.  For example
>>
>> StructType= "struct" "{" { FieldDecl ";" } "}" .
>>
>> The rule as stated permits omitting the final ";" when the "}" follows
>> on the same line (if the "}" is on a different line, the ";" is
>> inserted automatically anyhow).  If we change to your version, we need
>> to rewrite the StructType production to not have a trailing ";", and
>> then rely on the new rule to permit adding one.
>>
>
> Ok, get it.
>
> But how about just change the second rule to the following instead.
>
> To allow complex statements to occupy a single line, a semicolon may be
> optional before a closing ")" or "}".
> Compilers will insert it back if it is absent.

I guess I'm not sure why that is any clearer than the current rule.

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] Are the semicolons rules some weird?

[digg]

btw, are there any cases a semicolon may be omitted before a closing ")"?

On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote:
>
> On Thu, Mar 8, 2018 at 8:43 AM,  > 
> wrote: 
> > 
> > There are two semicolon rules in Go spec: 
> > https://golang.org/ref/spec#Semicolons 
> > The first one states how a semicolon will be automatically inserted, 
> > however, the second one states how a semicolon can be omitted. 
> > Isn't more consistent to modify the second one to the following 
> description? 
> > 
> > To allow complex statements to occupy a single line, a semicolon may be 
> > inserted before a closing ")" or "}". 
>
> We would have to change a lot of the syntax productions.  For example 
>
> StructType= "struct" "{" { FieldDecl ";" } "}" . 
>
> The rule as stated permits omitting the final ";" when the "}" follows 
> on the same line (if the "}" is on a different line, the ";" is 
> inserted automatically anyhow).  If we change to your version, we need 
> to rewrite the StructType production to not have a trailing ";", and 
> then rely on the new rule to permit adding one. 
>
> 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] Are the semicolons rules some weird?

[digg]

On Thursday, March 8, 2018 at 11:49:18 AM UTC-5, Ian Lance Taylor wrote:
>
> On Thu, Mar 8, 2018 at 8:43 AM,  > 
> wrote: 
> > 
> > There are two semicolon rules in Go spec: 
> > https://golang.org/ref/spec#Semicolons 
> > The first one states how a semicolon will be automatically inserted, 
> > however, the second one states how a semicolon can be omitted. 
> > Isn't more consistent to modify the second one to the following 
> description? 
> > 
> > To allow complex statements to occupy a single line, a semicolon may be 
> > inserted before a closing ")" or "}". 
>
> We would have to change a lot of the syntax productions.  For example 
>
> StructType= "struct" "{" { FieldDecl ";" } "}" . 
>
> The rule as stated permits omitting the final ";" when the "}" follows 
> on the same line (if the "}" is on a different line, the ";" is 
> inserted automatically anyhow).  If we change to your version, we need 
> to rewrite the StructType production to not have a trailing ";", and 
> then rely on the new rule to permit adding one. 
>
>
Ok, get it.

But how about just change the second rule to the following instead.

To allow complex statements to occupy a single line, a semicolon may be 
optional before a closing ")" or "}".
Compilers will insert it back if it is absent.

 

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

[go-nuts] Is there anyone using gomobile in production ?

[irmakserdar]

Hi,

Gomobile is in maintenance mode, has lots of open issues and it's usage seems 
decreasing on surveys.

Is there anyone using it in production ?

What do you think about the future of gomobile ?

My Best,
Serdar

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Are the semicolons rules some weird?

[Ian Lance Taylor]

On Thu, Mar 8, 2018 at 8:43 AM,   wrote:
>
> There are two semicolon rules in Go spec:
> https://golang.org/ref/spec#Semicolons
> The first one states how a semicolon will be automatically inserted,
> however, the second one states how a semicolon can be omitted.
> Isn't more consistent to modify the second one to the following description?
>
> To allow complex statements to occupy a single line, a semicolon may be
> inserted before a closing ")" or "}".

We would have to change a lot of the syntax productions.  For example

StructType= "struct" "{" { FieldDecl ";" } "}" .

The rule as stated permits omitting the final ";" when the "}" follows
on the same line (if the "}" is on a different line, the ";" is
inserted automatically anyhow).  If we change to your version, we need
to rewrite the StructType production to not have a trailing ";", and
then rely on the new rule to permit adding one.

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.

[go-nuts] Re: Building Go

[matthewjuran]

While an old Go program will compile with new versions, new Go programs may 
not compile with old versions due to added standard library APIs.

Matt

On Thursday, March 8, 2018 at 10:32:35 AM UTC-6, Krzysztof Kwiatkowski 
wrote:
>
> Hi,
>
>
> I've quite newbe question, but I would like to double-check my 
> understanding before doing something stupid.
>
>
> I'm building a toolchain for which I need to compile go from sources (I 
> modify the sources). In order to compile Go I need some version of Go to be 
> installed on my system.
>
> Does it matter which version of go I use to compile? 
>
> It will matter for things like performance, but I'm concerned purely about 
> correctness of the build.
>
>
> My understanding is that it doesn't - as according to documentation here 
> https://golang.org/doc/install/source, it's OK to use any compiler 
> version to compile go from source. Is my understanding correct?
>
>
> Kris
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Debugging unit tests in go

[Ian Lance Taylor]

On Thu, Mar 8, 2018 at 4:41 AM,   wrote:
>
> How can I debug the unit tests in go ? Normal executible I debug with gdb or
> delve.
> I am running from command prompt go test -v ./test/... -run Test_Connect.

Run `go  -test c PKG` to get an executable for the package PKG.  You
can then run that executable with -test.v and test.run options.

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] Building Go

[Ian Lance Taylor]

On Thu, Mar 8, 2018 at 3:53 AM, Krzysztof Kwiatkowski
 wrote:
>
>
> I've quite newbe question, but I would like to double-check my understanding
> before doing something stupid.
>
>
> I'm building a toolchain for which I need to compile go from sources (I
> modify the sources). In order to compile Go I need some version of Go to be
> installed on my system.
>
> Does it matter which version of go I use to compile?
>
> It will matter for things like performance, but I'm concerned purely about
> correctness of the build.
>
>
> My understanding is that it doesn't - as according to documentation here
> https://golang.org/doc/install/source, it's OK to use any compiler version
> to compile go from source. Is my understanding correct?

It doesn't matter which version of Go you use to build your own Go
toolchain, as long as you use version 1.4 or later.

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.

[go-nuts] Are the semicolons rules some weird?

[digg]

There are two semicolon rules in Go spec: 
https://golang.org/ref/spec#Semicolons
The first one states how a semicolon will be automatically inserted,
however, the second one states how a semicolon can be omitted.
Isn't more consistent to modify the second one to the following description?

To allow complex statements to occupy a single line, a semicolon may be 
inserted before a closing ")" or "}". 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Building Go

[Krzysztof Kwiatkowski]

 

Hi,


I've quite newbe question, but I would like to double-check my 
understanding before doing something stupid.


I'm building a toolchain for which I need to compile go from sources (I 
modify the sources). In order to compile Go I need some version of Go to be 
installed on my system.

Does it matter which version of go I use to compile? 

It will matter for things like performance, but I'm concerned purely about 
correctness of the build.


My understanding is that it doesn't - as according to documentation here 
https://golang.org/doc/install/source, it's OK to use any compiler version 
to compile go from source. Is my understanding correct?


Kris

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Is gomobile have future and is there anyone using it in production ?

[sirmak]

Hi,

Gomobile is in maintenance mode, has lots of open issues and it's usage 
seems decreasing on surveys.

Is there any development plan/future for gomobile? And is there anyone 
using it on production ?

My Best,
Serdar

-- 

Follow us:  
  

--

--

*- Bu e-posta mesaj ve ekleri sadece gönderildigi kisi veya kuruma özeldir. 
Dogru aliciya ulasmamis olmasi halinde, bu mesajin baska bir aliciya 
yonlendirilmesi, kopyalanmasi veya kullanilmasi yasaktir.*

*- This e-mail and any attachments transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the intended recipient you are hereby notified 
that any forwarding, copying or use of the information is prohibited.*

*--*

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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

[parthasarathi . kundu]

Hi,
How can I debug the unit tests in go ? Normal executible I debug with gdb 
or delve.
I am running from command prompt go test -v ./test/... -run Test_Connect.

Any thing better with ide ?

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] golang tcp transport just like nc

[Jamil Djadala]

On Wed, 7 Mar 2018 19:16:33 -0800 (PST)
sucong...@gmail.com wrote:

> 
> 
> linux nc command port to golang 
> 
> 
> in nc , we can do this
> 
> echo 'my id is 1' > /tmp/1
> echo 'my id is 3' > /tmp/3
> rm -rf /tmp/2 /tmp/4
> 
> 
> 
> server
> 
> nc -l 19090 < /tmp/1 > /tmp/2
> 
> ( if you are in linux not mac this may be  ` nc -l -p 19090 `  )
> 
> client
> 
> 
> nc 127.0.0.1 19090 < /tmp/3 > /tmp/4
> 
> 
> when finish ,both server and client will be closed
> 
> client send /tmp/3 is saved by server to /tmp/2
> 
> server send /tmp/1 is saved by server to /tmp/4
> 
> then use golang do the same thing , but when finished , both server
> and client can not closed automaticly
> 
> 
> 
> echo 'my id is 1' > /tmp/1
> echo 'my id is 3' > /tmp/3
> rm -rf /tmp/2 /tmp/4
> 
> 
> 
> 
> 
> ./nc serer < /tmp/1 > /tmp/2
> 
> 
> 
> ./nc  < /tmp/3 > /tmp/4
> 
> 
> 
> please help me how to solve this and works like nc 
> 
> 
> example code 
> 
> https://gist.github.com/suconghou/a1bfab9a30b3408400b6382d73051227
> 
> 
> 

See
https://play.golang.org/p/6ljoK4EB9iY

You must use CloseRead/CloseWrite

Jamil Djadala


-- 
Jamil Djadala

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Get Programming with Go

[matthewjuran]

>
> I'm not sure if "in English" really describes Go. Languages like Ruby 
> purport to offer English-like syntax (see "Beautiful Code: Leading 
> Programmers Explain How They Think") through metaprogramming tricks. On the 
> other hand, Go strives for simplicity and, in my opinion, clarity -- even 
> at the cost of verbosity in some cases. Whereas Ruby "reads like an essay", 
> code written in Go "does what it says."


Well there’s the capitalization for export rule, the keywords and built-in 
identifiers are English, and all toolchain comments and API are in English. 
There's discussion about a transliteration tool and translation strategy 
here: https://groups.google.com/forum/#!topic/golang-dev/BJXwjd3VEfM

Thanks for the discount code.

Matt

On Wednesday, March 7, 2018 at 9:09:26 PM UTC-6, Nathan Youngman wrote:
>
> Hi Matthew,
>
> First of all, thanks for looking at the free chapters and providing 
> feedback.
>
> I think I should reword the paragraph about the data centre, because there 
> is what Go was initially announced as, and then there is the niche that it 
> now occupies -- the later being predominately network services that tend to 
> run in data centres (65% according to 
> https://blog.golang.org/survey2017-results).
>
> I'm not sure if "in English" really describes Go. Languages like Ruby 
> purport to offer English-like syntax (see "Beautiful Code: Leading 
> Programmers Explain How They Think") through metaprogramming tricks. On the 
> other hand, Go strives for simplicity and, in my opinion, clarity -- even 
> at the cost of verbosity in some cases. Whereas Ruby "reads like an essay", 
> code written in Go "does what it says."
>
> The book layout isn't final, as it's still in early access. I think it 
> will look much nicer after it goes through the production phase -- finger's 
> crossed. A fair amount of that is outside of my control as the author. Even 
> the book cover is out of my hands, though I can and have given the 
> publisher feedback.
>
> As far as competition, the only book that comes to mind as 
> beginner-oriented is Caleb Doxsey's "Introducing Go" published through 
> O'Reilly. There may be others that I'm not aware of. 
> http://shop.oreilly.com/product/0636920046516.do I'm not sure if either 
> Caleb's book or ours is suitable for the absolute beginner. Learning 
> something like Scratch may be advisable first, to get the concepts down.
>
> Nathan.
>
> P.S. If you decide to buy a copy or recommend it to others, the discount 
> code *39youngman* will give 39% off either the paper book or ebook. Also, 
> my affiliate link earns me a few bucks: https://bit.ly/programminggo
>
>
> On 7 March 2018 at 09:02, > wrote:
>
>> Go is designed for the modern data center, but its adoption isn’t 
>>> restricted to the workplace. 
>>
>>
>> While the garbage collector may point to this, and I’ve previously argued 
>> about data centers stepping on other applications’ feet, my understanding 
>> is the stated goal is systems programming. This term encompasses anything 
>> designed as part of a larger system in my mind; OS drivers and components 
>> have been mentioned, the compiler is written in Go, build and other scripts 
>> are easy to write in Go, OS CLI tools are great in Go, you’ve mentioned 
>> embedded programming, small web servers with database definitely work, and 
>> of course data center applications and infrastructure are a major Go target 
>> and consumer.
>>
>> Perhaps something like “Go is designed for programming modern computers 
>> and computer systems in English” would be more accurate?
>>
>> I’ve only looked at the three free chapters, but one thing that stands 
>> out to me is the amount of formatting on each page. Although I’m looking on 
>> a computer and not at a book, it seems that all of the italics, bolds, 
>> blocks, lines, references, pictures, and other formatting add noise. I do 
>> think the graphics are creative, slicing the solar system is great.
>>
>> It’s been asked here about references for new programmers but I didn’t 
>> have an answer besides “what do you want to know?”. Can you share your 
>> competition here? I’ll mention “Get Programming with Go” in the future.
>>
>> Thanks,
>> Matt
>>
>> On Wednesday, March 7, 2018 at 8:46:58 AM UTC-6, Nathan Youngman wrote:
>>>
>>> Learn about error handling and concurrent state in the latest release of 
>>> Get Programming with Go, available from Manning Books.
>>>
>>> The first draft is complete. If you have any feedback, now’s the time to 
>>> get it in, as we are currently editing the book before it goes to 
>>> production.
>>>
>>> https://bit.ly/programminggo
>>>
>>>
>>> -- 
>> 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/_-35shjZqUU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups

Re: [go-nuts] fast small prime checker

[ralphdoncaster]

It does look interesting, though I think I have a solution using git 
submodules.

On Monday, 5 March 2018 02:26:53 UTC-4, Michael Jones wrote:
>
> ...if that's how you feel, you'll enjoy the current discussion of vgo.
>
> On Sun, Mar 4, 2018 at 10:24 PM, > 
> wrote:
>
>>
>>
>> On Monday, 5 March 2018 02:13:18 UTC-4, Jan Mercl wrote:
>>>
>>>
>>> On Mon, Mar 5, 2018 at 12:55 AM  wrote:
>>>
>>> > For my use case, I'll only be checking numbers > 2^18 and < 2^25. 
>>> After looking at the repo, it's not simple enough to copy primes.go, anyone 
>>> that wants to rely on it would have to fork the repo.
>>>
>>> No need to copy source code or fork the repository. `import 
>>> example.com/foo/bar`  and `$ go get 
>>> example.com/foo/bar`  is all what's need to 
>>> use a package in any program.
>>>
>>> -- 
>>>
>>> -j
>>>
>>
>> I said anyone who wants to "rely" on it.  i.e. not just today, but 
>> tomorrow, next month, and next year.  Aside from official golang packages 
>> like golang.org/x/crypto, it's not safe to import 3rd party packages.  
>> The author/maintainer of the repository could delete it, it could be hit 
>> with a DMCA takedown, etc.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

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

Re: [go-nuts] Re: Channels vs Actors

[Jesper Louis Andersen]

On Thu, Mar 8, 2018 at 10:37 AM Haddock  wrote:

> The fundamental problem with asynchronous programming is that asynchronous
> messages that depend on each other from the application logic "may not
> meet" and miss each other. Let's say, several threads start to search
> through a pile of data starting from different offsets. Somehen one thread
> has found the needle, now the other threads do not need to continue
> searching any more. How to tell them to cancel their search? This is not
> easy and therefore is a good simple example to show problems in
> asynchronous programming, but only a simple one. There are hell of problem
> situations of similar nature with asynchronous programming ...
>
>
On particular weakness of the pure actor models are that they always
process messages in an unordered fashion. This is yet another of those
cases where "Erlang doesn't implement the actor model". Not only can you
select which messages to process in a given state. You also have a FIFO
guarantee among pairs of processes. And this is crucial because it allows
you to limit the state space of possible events that can occur.

As for the search-for-a-needle problem, you need either something like
package "context" in Go, or links like in Erlang. You simply link together
all the searchers. The first one to find a needle, sends off a message and
then terminates. Because it is linked to the other processes, they also
terminate. If two processes both find a needle at the same time, you have
two answers, but you can do whatever you want with that in the receiver.
Note that in Erlang, because of process isolation, abrupt termination is
usually safe. If you have cleanup to do, you can always ask the process to
turn the termination into a message, but then you are also obliged to
periodically taste your mailbox to make sure there are no such message in
it.

I agree that asynchronous messaging is harder than a single thread or
synchronous messaging. But:

* It is necessary in a lot of cases.
* It is very often faster because there is a lot less contention going on.
Especially in the latency department.
* Properly written, it tend to be more flexible.
* If it schedules preemptively, then async systems are more robust against
a few rogue parts of the system taking too long time.

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

Re: [go-nuts] golang tcp transport just like nc

[Peter Waller]

Once you've read all of os.Stdin, and the io.Copy finishes, you need to
call conn.CloseWrite(), to signal to the other side that it won't receive
any more bytes. Otherwise each side is blocked in io.Copy(os.Stdout, conn)
waiting for more bytes to arrive from the other side.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] How to integrate ckeditor and ckfinder for golang website ?

[Lutz Horn]

I'm designing a golang website, You need to integrate ckeditor and
ckfinder for your website. Thank you very much.


Do you mean the tools provided by https://ckeditor.com/?

You integrate them into your web site by following the documentation of 
these products:


* https://docs.ckeditor.com/ckeditor4/latest/
* https://docs.ckeditor.com/ckfinder/latest/

This is not related to Go.

Lutz

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] How to integrate ckeditor and ckfinder for golang website ?

[thanhsang . dang]

I'm designing a golang website, You need to integrate ckeditor and ckfinder 
for your website. Thank you very much.

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

Re: [go-nuts] Re: Channels vs Actors

[Haddock]

>
>
>
>> Actors have an advantage when used for distributed systems. If two actors 
>> on different boxes communicate with each other it is not a problem to make 
>> communication work without data loss through the principle of supervision. 
>> Supervision is the idea Joe Armstrong (the creator of Erlang) described in 
>> his PhD thesis. If two actors communicating with each other, realize 
>> something in the communication must have gone wrong (timeout waiting for 
>> ack, etc.), a third supervisory actor is informed which resets both actors 
>> who then restart from some safe point. There are hierarchies of supervisory 
>> actors to deal with the problem that also a superviory actor may hang or be 
>> subject to data loss. 
>>
>
It would be a nice project to develop distributed channels in Go where 
dataloss through the wire cannot happen, because the implementation of 
those distributed channels relies on supervision. Maybe in Go 1.11 ? :-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Channels vs Actors

[Haddock]

Am Donnerstag, 8. März 2018 10:17:02 UTC+1 schrieb Anto Aravinth:
>
> Thanks everyone and thanks Haddock for such a detailed response. Few 
> questions:
>
> On Thu, Mar 8, 2018 at 2:32 PM, Haddock > 
> wrote:
>
>> The main difference is that goroutines do blocking takes from channels 
>> whereas actors receive asynchronous events. This means that actors have to 
>> deal with all the situations in asynchronous programming that are 
>> inherently difficult to deal with (inherently means there is no general way 
>> to solve this and never will be).
>>
> Why we are calling out its difficult to handle asynchronous programming? 
> I have done many node js project in real world, and for me if once you 
> understand how asynchronous programming works, its simple mental model. I 
> just feel interested, as you have said it would be difficult to handle 
> them. 
>

The fundamental problem with asynchronous programming is that asynchronous 
messages that depend on each other from the application logic "may not 
meet" and miss each other. Let's say, several threads start to search 
through a pile of data starting from different offsets. Somehen one thread 
has found the needle, now the other threads do not need to continue 
searching any more. How to tell them to cancel their search? This is not 
easy and therefore is a good simple example to show problems in 
asynchronous programming, but only a simple one. There are hell of problem 
situations of similar nature with asynchronous programming ...

The problem with asynchronous programming is when doing concurrent things. 
When things run in parallel, there is no problem as there is no 
concurrency. Concurrency means that different threads need access to the 
data read and changed by other threads. A lot of business applications do 
things just in parallel. When someone changes his facebook page the change 
only concerns the account of that user, not of other users. Same for all 
other facebook users. So there is no concurrency and no difficulty in 
sychronizing shared state correctly between threads without race 
conditions, deadlocks, outlooks, live locks and all that.

Because many business applications are parallel and not concurrent, actors 
or just plain threads work well. This is then misused by the marketing guys 
by saying that actors make multi-threading easy. It is only true when 
things are in parallel and there is no or little concurrency. With heavy 
concurrency CSP is just great (albeit not pre-emptive and not when 
distributed).
 

>  
>
>>
>> The approach with blocking takes as in CSP and in Go runs into a problem 
>> when a thread blocked by an empty channel is lost for the application. 
>> Somehen then operationg system has no memory left to create new threads. 
>> This is being dealt with by having so called green threads (called 
>> goroutines in Go). Green threads have a reduced context and therefore 
>> consume less memory. On a machine with 4 GB RAM you can create about 2000 
>> OS threads but about 80.000 goroutines (I once tried it out). So in Go you 
>> don't run into the problem that many empty channels with threads being 
>> blocked by them till they receive input can make the application go out of 
>> threads.
>>
>
> I guess, its 80,000. Should be a typo. Also all goroutines are called as 
> green threads? I read somewhere they start with stack size of 4k, and 
> expand when needed. Correct me if I'm wrong here.  
>

No typo, in my country the dot is the thousands separator ;-). But I will 
change to a comma when posting to an English speaking forum. 

Nice, not sure if coroutines in kotlin are same as Goroutine -- mainly they 
> also work as "green threads"?
>


You cannot have green threads on the JVM as the JVM does not have them. The 
workaround is to make use of fibers instead. See for example Quasar 
, which is already doing that. 
Project Loom  
inside Oracle is about making changes to the JVM to better support 
CSP-style additions. This video on youtube 
 is a good presentation about 
fibers by the creator of Quasar and the owner of project Loom at Oracle.
 

>  
>
>>
>> Am Sonntag, 4. März 2018 18:00:54 UTC+1 schrieb Anto Aravinth:
>>>
>>> Hello All, 
>>>
>>> I'm new to golang and trying to understand the difference between 
>>> channels and actors. From my knowledge:
>>>
>>> 1. Golang support channels, which is concurrently safe
>>> 2. Channels can be shared across goroutines that are running. (very much 
>>> similar to messages)
>>>
>>> Actors:
>>> 1. They are based on messages. 
>>> 2. Messages are immutable by nature. 
>>> 3. Actors work based on messages, concurrently. 
>>>
>>> I find actors and channels much similar, may be I'm wrong here. Any help 
>>> would be really good. 
>>>
>>> Thanks, 
>>> Anto;
>>>
>> -- 
>> You received this message because you are subscribed to a top

Re: [go-nuts] Re: Channels vs Actors

[Anto Aravinth]

Thanks everyone and thanks Haddock for such a detailed response. Few
questions:

On Thu, Mar 8, 2018 at 2:32 PM, Haddock  wrote:

> The main difference is that goroutines do blocking takes from channels
> whereas actors receive asynchronous events. This means that actors have to
> deal with all the situations in asynchronous programming that are
> inherently difficult to deal with (inherently means there is no general way
> to solve this and never will be).
>
Why we are calling out its difficult to handle asynchronous programming? I
have done many node js project in real world, and for me if once you
understand how asynchronous programming works, its simple mental model. I
just feel interested, as you have said it would be difficult to handle
them.


>
> The approach with blocking takes as in CSP and in Go runs into a problem
> when a thread blocked by an empty channel is lost for the application.
> Somehen then operationg system has no memory left to create new threads.
> This is being dealt with by having so called green threads (called
> goroutines in Go). Green threads have a reduced context and therefore
> consume less memory. On a machine with 4 GB RAM you can create about 2000
> OS threads but about 80.000 goroutines (I once tried it out). So in Go you
> don't run into the problem that many empty channels with threads being
> blocked by them till they receive input can make the application go out of
> threads.
>

I guess, its 80,000. Should be a typo. Also all goroutines are called as
green threads? I read somewhere they start with stack size of 4k, and
expand when needed. Correct me if I'm wrong here.

>
> Actors have an advantage when used for distributed systems. If two actors
> on different boxes communicate with each other it is not a problem to make
> communication work without data loss through the principle of supervision.
> Supervision is the idea Joe Armstrong (the creator of Erlang) described in
> his PhD thesis. If two actors communicating with each other, realize
> something in the communication must have gone wrong (timeout waiting for
> ack, etc.), a third supervisory actor is informed which resets both actors
> who then restart from some safe point. There are hierarchies of supervisory
> actors to deal with the problem that also a superviory actor may hang or be
> subject to data loss.
>
> Also, actors are served by normal threads (making use of thread pools to
> keep the number of memory intensive threads low). These normal threads do
> not have a reduced context, but a full one. This means that the information
> is present where some preemption took place where the thread needs to
> continue when resumed after suspension. Not so for green threads, because
> of their context being reduced, they are not pre-emptive. The developer in
> some situations needs to know that the current green thread/goroutine needs
> to yield for things to continue.
>
> Channels in Go or CSP in general, on the contrary, rely on data exchange
> between channels to be free from any data loss. Otherwise the application
> may sit forever on some empty channel. This is no problem for channels
> inside the same instance of some program, but it is a problem in
> distributed systems that have to deal with communication through networks
> being unreliable.
>
> In general with CSP-style concurrency it is much easier to get process
> synchronization right. If there is a problem, it is much easier to spot it
> and also to fix it. If have spent years of reproducing race conditions and
> deadlocks and fixing them with "traditional" programming languages without
> CSP. Saying that CSP makes concurrent programming much easier is something
> I can confirm from real-world experience. But they don't work well in
> distributed systems and when pre-emption is a necessity (shut down nuclear
> power plant when temperature threshold is exceeded here and now).
>
> There is also CSP in the working for the JVM with Coroutines in Kotlin and
> project Loom for the JVM. The advantes of CSP for server-side programming
> and concurrency in general have become apparent also to other people ... ;-)
>
> Nice, not sure if coroutines in kotlin are same as Goroutine -- mainly
they also work as "green threads"?


>
> Am Sonntag, 4. März 2018 18:00:54 UTC+1 schrieb Anto Aravinth:
>>
>> Hello All,
>>
>> I'm new to golang and trying to understand the difference between
>> channels and actors. From my knowledge:
>>
>> 1. Golang support channels, which is concurrently safe
>> 2. Channels can be shared across goroutines that are running. (very much
>> similar to messages)
>>
>> Actors:
>> 1. They are based on messages.
>> 2. Messages are immutable by nature.
>> 3. Actors work based on messages, concurrently.
>>
>> I find actors and channels much similar, may be I'm wrong here. Any help
>> would be really good.
>>
>> Thanks,
>> Anto;
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
>

[go-nuts] Re: Channels vs Actors

[Haddock]

The main difference is that goroutines do blocking takes from channels 
whereas actors receive asynchronous events. This means that actors have to 
deal with all the situations in asynchronous programming that are 
inherently difficult to deal with (inherently means there is no general way 
to solve this and never will be).

The approach with blocking takes as in CSP and in Go runs into a problem 
when a thread blocked by an empty channel is lost for the application. 
Somehen then operationg system has no memory left to create new threads. 
This is being dealt with by having so called green threads (called 
goroutines in Go). Green threads have a reduced context and therefore 
consume less memory. On a machine with 4 GB RAM you can create about 2000 
OS threads but about 80.000 goroutines (I once tried it out). So in Go you 
don't run into the problem that many empty channels with threads being 
blocked by them till they receive input can make the application go out of 
threads.

Actors have an advantage when used for distributed systems. If two actors 
on different boxes communicate with each other it is not a problem to make 
communication work without data loss through the principle of supervision. 
Supervision is the idea Joe Armstrong (the creator of Erlang) described in 
his PhD thesis. If two actors communicating with each other, realize 
something in the communication must have gone wrong (timeout waiting for 
ack, etc.), a third supervisory actor is informed which resets both actors 
who then restart from some safe point. There are hierarchies of supervisory 
actors to deal with the problem that also a superviory actor may hang or be 
subject to data loss. 

Also, actors are served by normal threads (making use of thread pools to 
keep the number of memory intensive threads low). These normal threads do 
not have a reduced context, but a full one. This means that the information 
is present where some preemption took place where the thread needs to 
continue when resumed after suspension. Not so for green threads, because 
of their context being reduced, they are not pre-emptive. The developer in 
some situations needs to know that the current green thread/goroutine needs 
to yield for things to continue.

Channels in Go or CSP in general, on the contrary, rely on data exchange 
between channels to be free from any data loss. Otherwise the application 
may sit forever on some empty channel. This is no problem for channels 
inside the same instance of some program, but it is a problem in 
distributed systems that have to deal with communication through networks 
being unreliable.

In general with CSP-style concurrency it is much easier to get process 
synchronization right. If there is a problem, it is much easier to spot it 
and also to fix it. If have spent years of reproducing race conditions and 
deadlocks and fixing them with "traditional" programming languages without 
CSP. Saying that CSP makes concurrent programming much easier is something 
I can confirm from real-world experience. But they don't work well in 
distributed systems and when pre-emption is a necessity (shut down nuclear 
power plant when temperature threshold is exceeded here and now).

There is also CSP in the working for the JVM with Coroutines in Kotlin and 
project Loom for the JVM. The advantes of CSP for server-side programming 
and concurrency in general have become apparent also to other people ... ;-)

Am Sonntag, 4. März 2018 18:00:54 UTC+1 schrieb Anto Aravinth:
>
> Hello All, 
>
> I'm new to golang and trying to understand the difference between channels 
> and actors. From my knowledge:
>
> 1. Golang support channels, which is concurrently safe
> 2. Channels can be shared across goroutines that are running. (very much 
> similar to messages)
>
> Actors:
> 1. They are based on messages. 
> 2. Messages are immutable by nature. 
> 3. Actors work based on messages, concurrently. 
>
> I find actors and channels much similar, may be I'm wrong here. Any help 
> would be really good. 
>
> Thanks, 
> Anto;
>

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