Re: [go-nuts] Go language should become an ANSI and ISO standard.

[beoran]

I understand very well what the risks of standardization can be. Look at
how the C language was maimed during standardization by 104 instances of
undefined behavior.

But that is not what I am getting at. Five years ago I was somewhat
involved in the effort to make Ruby an ISO standard language. From the get
go it was a largely bureaucratic effort. We specified a common sub set of a
then already old version of Ruby and made enough loopholes to make sure
that any Ruby out there could be considered confirming to the standard.

Why? You can perhaps not appreciate how powerful the bureaucrats can be in
some countries and corporations. Since Ruby became an ISO standard, I have
been able to convince those bureaucrats to let me use Ruby where I was
barred from doing so before.

For Go language it is now the same. Bureaucrats don't know Go, and because
it is not standardized, I often encounter a "no go". A Ruby style standard
that would allow developers to check the "ISO standard language" box would
allow us to convince those bureaucrats to let us use Go much more widely.

Like Michael Jones suggest, we would only standardize Go as it is, and not
use the standardization process to let it decide the language features. And
only update the standard once the new features are settled. That avoids
design by committee as well.

For these reasons I think, when done properly, the effort will be worth
while in the end.

Kind Regards,

B.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] A concrete proposal re: using interfaces instead of contracts in Go 2 generics.

[Ian Denhardt]

I've seen a lot of folks expressing the sentiment "we should just use
interfaces instead of this new contract thing." Most of the discussion
I've seen around this jumps right to operator overloading without being
terribly explicit about the general case; I've written a proposal
focusing on the latter:

https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d

(It is also linked from the feedback wiki page).

It punts on operator overloading, though discusses some related
subtleties.

Thoughts?

-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] Casting Back from nested Struct

[Marvin Renich]

* Chris Hopkins  [181010 12:04]:
> Hi,
> I appreciate this is not possible, but realised I never understood why (so 
> have just been working around it).
> Example code at:
> https://play.golang.org/p/BgFL9T0KiC7
> 
> I can create a struct with other structs as a member. I then get all the 
> fields and methods associated with that member.
> But you can't cast from that master struct back to the member struct. 
> i.e. I can create a type T with subtype S and operate on the members and 
> data within S, but can't cast T to S.
> I guessed that when you define type S, it exists as effectively a pointer 
> to a struct, and then members within that struct are an indexed offset from 
> that pointer. The act of creating S within T is simply extending that 
> definition so that T's new fields start where S's finished. Casting back 
> from T should therefore be trivial, but clearly it isn't :-)
> 
> I'm sure there's a good reason, but it escapes me at the moment. Any ideas?

While my answer below is correct and more technical, I think the answer
Burak Serdar gave, that embedding is composition not inheritance, may be
more helpful in understanding why you might have believed that it should
work when it doesn't.

However, in the interest of clearer communication between gophers, I am
going to wax pedantic.  Go does not have any syntactic construct called
a cast.  It has conversions and type assertions.

Type assertions are used to change a value from a concrete type to an
interface type which it implements, an interface type to the concrete
type currently held by that value, or an interface type to another
interface type which the concrete type also implements.

Some type assertions can be determined to be illegal at compile time,
others can produce a runtime panic (if the v, ok = x.(T) assignment form
is not used).

Conversions come in two flavors:  those that change the underlying
representation of the value and those that don't.  The ones that do
either convert from one numeric type to another (e.g. uint to float64),
or convert to or from a string type (e.g. []byte to string).

For all other conversions, the underlying types of the value being
converted and the type to which it is being converted must be identical
(a little extra verbiage is necessary for pointers, but the idea is the
same).

Conversions can always be type-checked at compile time and never produce
a runtime panic (out-of-memory notwithstanding).

In your example, c = Bob(f), you are attempting a conversion of f (type
Fred) to type Bob.  But Bob and Fred do not have identical underlying
types so you cannot convert f to type Bob.

You can, however, say c = f.Bob, since embedding Bob (the type) creates
a field named Bob.

...Marvin

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

Re: [go-nuts] Re: Is it safe to run go build in parallel?

[Yulrizka]

It seems that after searching in google, I found couple of similar issue:

most of them are related to parallel build with "GNU parallel" which is in 
our case as well.

https://github.com/gravitational/teleport/issues/1708
https://github.com/grpc/grpc-go/issues/368
https://github.com/vmware/vic/issues/5230

This is even before GO 1.11 or go mod.

And one thing, I noticed that this is not about GOCACHE, looks like package 
installed binaries example:

/var/lib/jenkins/workspace/project/src/go/pkg/linux_
amd64_netgo/project/thrift/gen/denormalized.a

while in our jenkins, `go env` says: 
...
GOCACHE="/var/lib/jenkins/.cache/go-build"
...



On Monday, October 1, 2018 at 7:56:46 PM UTC+2, Mark Rushakoff wrote:
>
> I saw that you wrote
>
> > The reason that I'm using shared GOPATH for this Jenkins step/job is 
> that to now download the packages in `pkg/mod`.
>
> And I thought that meant you were using modules.
>
> Discussion in https://github.com/golang/go/issues/26677 says that the 
> build cache is explicitly safe, but if you have a reproducer that shows 
> otherwise, that's probably worthy of its own issue.
>
> On Mon, Oct 1, 2018 at 10:50 AM Yulrizka > 
> wrote:
>
>> Hi Mark, 
>>
>> what I find interesting is that I haven't enable go module yet. 
>> As you can see in the errors that I'm still using a vendor directory
>>
>> On Monday, October 1, 2018 at 6:27:57 PM UTC+2, Mark Rushakoff wrote:
>>>
>>> https://github.com/golang/go/issues/26794 is "can't run go builds 
>>> concurrently if they download modules".
>>>
>>> In that issue, Russ says:
>>> > There is a plan to make downloading of modules by parallel go 
>>> commands safe but we haven't done that yet.
>>>
>>> On Monday, October 1, 2018 at 8:43:00 AM UTC-7, Yulrizka wrote:

 Hi,

 Recently, I played around with our Jenkins pipeline. In the new set-up, 
 I build multiple packages in parallel. This step executes "go build" for 
 each of the services that we have at the same time.
 One thing I also change is that for each service, it uses the same 
 GOPATH.

 Sometimes, I see failures like this

 src/go/pkg/linux_amd64_netgo/project/vendor/
 github.com/prometheus/common/internal/bitbucket.org/ww/goautoneg.a" 
 already exists and is not an object file

 go build project/vendor/github.com/prometheus/common/model: build 
 output 
 "/var/lib/jenkins/workspace/project/src/go/pkg/linux_amd64_netgo/project/vendor/
 github.com/prometheus/common/model.a" already exists and is not an 
 object file

 go build project/vendor/github.com/struCoder/pidusage: build output 
 "/var/lib/jenkins/workspace/project/src/go/pkg/linux_amd64_netgo/project/vendor/
 github.com/struCoder/pidusage.a" already exists and is not an object 
 file

 go build project/thrift/gen/denormalized: build output 
 "/var/lib/jenkins/workspace/project/src/go/pkg/linux_amd64_netgo/project/thrift/gen/denormalized.a"
  
 already exists and is not an object file


 My current guess is that this is because running multiple go build at 
 the same time, but I'm not sure if this is actually the case.

 If it is the case, what is the recommended way to build multiple 
 packages when you have multiple Jenkins step/job that build the binary at 
 the same time?

 The reason that I'm using shared GOPATH for this Jenkins step/job is 
 that to now download the packages in `pkg/mod`.


 Cheers!

>>> -- 
>> 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/Pj7BVrrBSuw/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] [Proposal] Goroutine Scoped Context

[Eyal]

Hi,
I wrote a proposal about making the context goroutine scoped.
Please read the current design problems and how I suggest to solve them:

https://posener.github.io/goroutine-scoped-context


Thanks,
Eyal

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

[Ian Lance Taylor]

On Wed, Oct 10, 2018 at 10:00 AM, robert engels  wrote:
>
> Ah, thanks. The read first, then possible deschedule/poll threw me.
>
> Doesn’t this mean though that as network traffic becomes very high, that the 
> connections might starve because the number of actual threads is capped 
> (GOMAXPROCS) - it would seem you pair the scheduling penalty twice this way, 
> once in OS kernel, and again in the Go scheduler ? Doesn’t the Go scheduler 
> than have to be as “fair” as the OS scheduler - seems complex and a possible 
> source of obscure starvation bugs.
>
> Does this mean that if my ‘fd’ is always ready (in a Go routine reading a 
> socket) - because lots of data coming in - I will never deschedule ? In an 
> alternative environment, if I wrote C and had multiple FDs in a poll, in can 
> ensure that they are read in order - is that happening behind the scenes ?
>
> Thanks, just curious more than anything.

The Go scheduler will preempt goroutines that have been running for
more than 10ms.

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] async IO

[robert engels]

Ah, thanks. The read first, then possible deschedule/poll threw me.

Doesn’t this mean though that as network traffic becomes very high, that the 
connections might starve because the number of actual threads is capped 
(GOMAXPROCS) - it would seem you pair the scheduling penalty twice this way, 
once in OS kernel, and again in the Go scheduler ? Doesn’t the Go scheduler 
than have to be as “fair” as the OS scheduler - seems complex and a possible 
source of obscure starvation bugs.

Does this mean that if my ‘fd’ is always ready (in a Go routine reading a 
socket) - because lots of data coming in - I will never deschedule ? In an 
alternative environment, if I wrote C and had multiple FDs in a poll, in can 
ensure that they are read in order - is that happening behind the scenes ?

Thanks, just curious more than anything.


> On Oct 10, 2018, at 11:45 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Oct 10, 2018 at 9:35 AM, robert engels  wrote:
>> 
>> It was my understanding that all IO in Go was async, and that behind the 
>> scenes when you made a network read, it enqueued the fd, descheduled the Go 
>> routine,  and performed a select/poll on some other thread, then based on 
>> the select, it would rescheduled the proper Go routine to perform the read.
>> 
>> But as I trace through the stdlib into UDPConn and down, I eventually see it 
>> make a Syscall6 using RECV_FROM - so I don’t see any of the ‘select/poll’ 
>> multiplexing?
>> 
>> Is this reading correct ? Was this previous behavior that was removed ?
> 
> I assume you traced it down to (*FD).ReadFrom in the internal/poll
> package?  That method will call the recvfrom system call first.  If
> that succeeds, great.  If that returns EAGAIN, then at that point we
> queue the descriptor with the runtime poller.  That is, we keep all
> descriptors in non-blocking mode, and optimistically try each
> operation once.  Only if the operation would block do we shift to
> using the poller.
> 
> 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] Go language should become an ANSI and ISO standard.

[Michael Jones]

I was the engineering director for OpenGL’s birth and growth at SGI and
have perspective on that process, and was for a long time a board member of
the Open Geospatial Consortium (OGC) and have views from those ISO-related
adventures.

I’m with Ian on this—I quite deeply respect standards but see them best as
“recognition of standard practice” rather than “political arena to fight
out new ideas.” The political aspect is not evil, it is simply
acknowledgement of the need to respect diverse stakeholders; but what is
bad about it, technically, is that the path finding of a small inspired
team easily gets lost in the chorus of multitudes wanting everything.

In UNIX you had a small inspired team. In almost every really great,
lasting technology you have <= 20 people, often <= 2, who are making the
contentious decisions. That is a critical number. The smallness allows a
cohesive thought process, which allows spirit and flow. Big groupthink
tends the other way, often with better individual decisions but with ideas
that seem almost randomly distributed across the design space.

I would vote to standardize Go 1 when Go 2 is out.

On Wed, Oct 10, 2018 at 8:16 AM Ian Lance Taylor  wrote:

> On Wed, Oct 10, 2018 at 7:55 AM, Beoran  wrote:
> >
> > In certain environments, such as for government contracting in certain
> countries, or for certain large corporations, or for developing safety
> critical applications using certain international standards, only
> programming languages that are officially standardized may be used. While
> Go would be an excellent language for such government or safety critical
> applications, it's acceptance is hampered due to the lack of an official
> standard.
> >
> > While this is in essence a formality, which would entail submitting the
> current Go language specification with the ANSI, and then have it propagate
> to the ISO, I do appreciate that will take quite some time and effort. But
> to further the acceptance of Go language, I would propose that Google
> invests the necessary resources to make this happen, with support from the
> community to edit the standard document if needed.
> >
> > The standard should probably be based on Go 1, since Go 2 is still
> largely undecided and probably 5 years in the future.
> >
> > If you are worried about using Go for safety critical applications
> consider this: it is rare that the compiler builder gives any safety
> warranty, although there are some safety certified C compilers. But for
> similar certified Go compilers to be developed, we need an official
> standard first.
> >
> > Even if the compiler is not certified, you can still use it if you
> validate it yourself. This implementation of go has extensive unit tests
> which simplifies such validation a lot.
> >
> > I know of some safety critical software that is implemented in C and
> compiled with GCC. As a language, Go is far safer than that, and that is
> also why we need a standard, to be able to get away from C for some safety
> applications.
>
> There are significant disadvantages to the standardization process.
>
> It is slow.
>
> It is easily politicized, with the possibility that changes to the
> language twill be determined by those with the patience and
> wherewithal to work through the standardization process, rather than
> those with a clear understanding of how the language will work best.
> This is not an inevitable result, but it is a risk.
>
> A likely approach to Go 2 is to roll out changes over time through a
> series of releases.  That would be inhibited by a standardization
> process.
>
> The advantages that you describe for standardization are essentially
> bureaucratic: some organizations require a certain approach, not
> because it is clearly better in all cases, but because that it their
> preferred process.  They could choose to change their requirements,
> with no affect on Go.  Meeting their requirements will inevitably have
> an effect on Go.
>
> I note that C was standardized nearly 20 years after it was developed,
> and C++ took about 16 years.  In both cases there were multiple
> implementations from different organizations, so there were additional
> benefits to standardization.  Go is not yet ten years old, and there
> are not as yet significant competing implementations.
>
> At this stage of the lifetime of the programming language, I think
> that the disadvantages outweigh the benefits.
>
> 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.
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.c

Re: [go-nuts] async IO

[Ian Lance Taylor]

On Wed, Oct 10, 2018 at 9:35 AM, robert engels  wrote:
>
> It was my understanding that all IO in Go was async, and that behind the 
> scenes when you made a network read, it enqueued the fd, descheduled the Go 
> routine,  and performed a select/poll on some other thread, then based on the 
> select, it would rescheduled the proper Go routine to perform the read.
>
> But as I trace through the stdlib into UDPConn and down, I eventually see it 
> make a Syscall6 using RECV_FROM - so I don’t see any of the ‘select/poll’ 
> multiplexing?
>
> Is this reading correct ? Was this previous behavior that was removed ?

I assume you traced it down to (*FD).ReadFrom in the internal/poll
package?  That method will call the recvfrom system call first.  If
that succeeds, great.  If that returns EAGAIN, then at that point we
queue the descriptor with the runtime poller.  That is, we keep all
descriptors in non-blocking mode, and optimistically try each
operation once.  Only if the operation would block do we shift to
using the poller.

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] async IO

[robert engels]

It was my understanding that all IO in Go was async, and that behind the scenes 
when you made a network read, it enqueued the fd, descheduled the Go routine,  
and performed a select/poll on some other thread, then based on the select, it 
would rescheduled the proper Go routine to perform the read.

But as I trace through the stdlib into UDPConn and down, I eventually see it 
make a Syscall6 using RECV_FROM - so I don’t see any of the ‘select/poll’ 
multiplexing?

Is this reading correct ? Was this previous behavior that was removed ?

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] Casting Back from nested Struct

[Burak Serdar]

On Wed, Oct 10, 2018 at 10:04 AM Chris Hopkins  wrote:
>
> Hi,
> I appreciate this is not possible, but realised I never understood why (so 
> have just been working around it).
> Example code at:
> https://play.golang.org/p/BgFL9T0KiC7
>
> I can create a struct with other structs as a member. I then get all the 
> fields and methods associated with that member.

Technically that's not true.  If you call a method on an embedded
struct field, the method has the embedded field as the receiver, not
the containing struct.

type S struct{}
func (s S) A() {}

type X struct {
  S
}
x:=X{}

Here, x.A() works on x.S, not x. The crucial difference is that this
is composition, not inheritance. The enclosing struct is not a subtype
of the enclosed struct.

One way to look at this is purely syntactical. If you have:

type Y struct {
   s S
}
y:=Y()

To call B(), you have to use the member name: y.s.B(). When the member
has no name, you simply drop the indirection, thus: x.B(), which is,
in fact, the same thing as x.S.B()







> But you can't cast from that master struct back to the member struct.
> i.e. I can create a type T with subtype S and operate on the members and data 
> within S, but can't cast T to S.
> I guessed that when you define type S, it exists as effectively a pointer to 
> a struct, and then members within that struct are an indexed offset from that 
> pointer. The act of creating S within T is simply extending that definition 
> so that T's new fields start where S's finished. Casting back from T should 
> therefore be trivial, but clearly it isn't :-)
>
>
> I'm sure there's a good reason, but it escapes me at the moment. Any ideas?
>
> Thanks
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and 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] Casting Back from nested Struct

[Chris Hopkins]

Hi,
I appreciate this is not possible, but realised I never understood why (so 
have just been working around it).
Example code at:
https://play.golang.org/p/BgFL9T0KiC7

I can create a struct with other structs as a member. I then get all the 
fields and methods associated with that member.
But you can't cast from that master struct back to the member struct. 
i.e. I can create a type T with subtype S and operate on the members and 
data within S, but can't cast T to S.
I guessed that when you define type S, it exists as effectively a pointer 
to a struct, and then members within that struct are an indexed offset from 
that pointer. The act of creating S within T is simply extending that 
definition so that T's new fields start where S's finished. Casting back 
from T should therefore be trivial, but clearly it isn't :-)


I'm sure there's a good reason, but it escapes me at the moment. Any ideas?

Thanks

Chris

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

[Ian Lance Taylor]

On Wed, Oct 10, 2018 at 7:55 AM, Beoran  wrote:
>
> In certain environments, such as for government contracting in certain 
> countries, or for certain large corporations, or for developing safety 
> critical applications using certain international standards, only programming 
> languages that are officially standardized may be used. While Go would be an 
> excellent language for such government or safety critical applications, it's 
> acceptance is hampered due to the lack of an official standard.
>
> While this is in essence a formality, which would entail submitting the 
> current Go language specification with the ANSI, and then have it propagate 
> to the ISO, I do appreciate that will take quite some time and effort. But to 
> further the acceptance of Go language, I would propose that Google invests 
> the necessary resources to make this happen, with support from the community 
> to edit the standard document if needed.
>
> The standard should probably be based on Go 1, since Go 2 is still largely 
> undecided and probably 5 years in the future.
>
> If you are worried about using Go for safety critical applications consider 
> this: it is rare that the compiler builder gives any safety warranty, 
> although there are some safety certified C compilers. But for similar 
> certified Go compilers to be developed, we need an official standard first.
>
> Even if the compiler is not certified, you can still use it if you validate 
> it yourself. This implementation of go has extensive unit tests which 
> simplifies such validation a lot.
>
> I know of some safety critical software that is implemented in C and compiled 
> with GCC. As a language, Go is far safer than that, and that is also why we 
> need a standard, to be able to get away from C for some safety applications.

There are significant disadvantages to the standardization process.

It is slow.

It is easily politicized, with the possibility that changes to the
language twill be determined by those with the patience and
wherewithal to work through the standardization process, rather than
those with a clear understanding of how the language will work best.
This is not an inevitable result, but it is a risk.

A likely approach to Go 2 is to roll out changes over time through a
series of releases.  That would be inhibited by a standardization
process.

The advantages that you describe for standardization are essentially
bureaucratic: some organizations require a certain approach, not
because it is clearly better in all cases, but because that it their
preferred process.  They could choose to change their requirements,
with no affect on Go.  Meeting their requirements will inevitably have
an effect on Go.

I note that C was standardized nearly 20 years after it was developed,
and C++ took about 16 years.  In both cases there were multiple
implementations from different organizations, so there were additional
benefits to standardization.  Go is not yet ten years old, and there
are not as yet significant competing implementations.

At this stage of the lifetime of the programming language, I think
that the disadvantages outweigh the benefits.

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] Visit London

[Paul Jolly]

Hi everyone,

London is famous for many things: the Royal Family, Buckingham Palace,
people standing in queues, Big Ben, the lack of air conditioning in
theatres, musicals. We could go on.

But did you know it's also famous for the Go London User Group (GLUG),
aka London Gophers?? :)

With over 2500 members, we meet on a monthly basis to enjoy:

* talks and chat about all-things Go
* good food and drink
* great company amongst friends

A key focus of London Gophers is to be an open, welcoming and
supportive community for anyone interested in Go. All of our events
fall under the Go Code of Conduct (https://golang.org/conduct) and we
are big fans of the Gopher Values (https://golang.org/conduct#values).

So if you are in town and would like to come and join us at one of our
meetups, you'd be more than welcome! Our next meetup is on Wed 17
October:

https://www.meetup.com/Go-London-User-Group/events/255136575/

Unfortunately we’re already full for October - 150 people signed up in
under 2 hours, with >150 people on the waitlist!  So follow us on
Twitter (https://twitter.com/LondonGophers) and join the Meetup group
(https://www.meetup.com/Go-London-User-Group/) for news about future
meetups.

We live-stream the talks from each meetup, and videos from past
meetups can be found on YouTube (https://youtube.com/c/LondonGophers).

Better still, if you are in town and would like to give a talk at one
of our meetups, let's get you booked in! First-time speakers are
especially welcome - we can help with refining your topic, preparing
the talk/format/slides etc. Please get in touch via
glug-organis...@googlegroups.com.

Thanks,


Paul and the GLUG Team

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

[Beoran]

In certain environments, such as for government contracting in certain 
countries, or for certain large corporations, or for developing safety critical 
applications using certain international standards, only programming languages 
that are officially standardized may be used. While Go would be an excellent 
language for such government or safety critical applications, it's acceptance 
is hampered due to the lack of an official standard.

While this is in essence a formality, which would entail submitting the current 
Go language specification with the ANSI, and then have it propagate to the ISO, 
I do appreciate that will take quite some time and effort. But to further the 
acceptance of Go language, I would propose that Google invests the necessary 
resources to make this happen, with support from the community to edit the 
standard document if needed.

The standard should probably be based on Go 1, since Go 2 is still largely 
undecided and probably 5 years in the future.

If you are worried about using Go for safety critical applications consider 
this: it is rare that the compiler builder gives any safety warranty, although 
there are some safety certified C compilers. But for similar certified Go 
compilers to be developed, we need an official standard first.

Even if the compiler is not certified, you can still use it if you validate it 
yourself. This implementation of go has extensive unit tests which simplifies 
such validation a lot.

I know of some safety critical software that is implemented in C and compiled 
with GCC. As a language, Go is far safer than that, and that is also why we 
need a standard, to be able to get away from C for some safety applications.

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

[go-nuts] rplidar_sdk_go - controlling the RPLidar scanner from Go

[Simon Ritchie]

Slamtec's RPLidar scanner is used in robotics, SLAM and solid modelling 
applications.  It's a small, light and cheap Lidar solution - versions are 
available for about $80.

Slamtec publish what they describe as an SDK.  Strictly it's just a C++ 
library of control methods and a few example applications.

I've written a wrapper for the C++ library that allows you to control the 
scanner from a Go program.  You can find that here: 
https://github.com/goblimey/rplidar_sdk_go.

Slamtec's C++ library is open source and is implemented for Windows, Mac 
and Linux systems.  I've only tested it under Linux so far.  Unfortunately, 
the Windows build requires a particular version of Visual Studio, which was 
a blocker for me.

I used cgo to call the C++ methods from Go.  There is a huge range of C and 
C++ libraries out there, and cgo potentially opens up access to them.  
However, the Slamtec library is not directly compatible with cgo and I had 
to jump through a few hoops to use it.  I describe them in the project 
README.  Anybody planning a similar project may get some useful advice 
there.

Enjoy!

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