[go-nuts] Re: On Accepting Interfaces and Structs

[jake6502]

The example gives me a better understanding of what you are doing, though 
still not much understanding as to *why *you are doing it this way. 
Usually, if I feel that code has a "smell" in Go, there is a way to rethink 
the basic design resulting more "natural" code. But without a full 
understanding of the real situation, it is impossible to say if that 
applies here. But lets assume for now that you must have multiple packages 
that all contain functions that return a common struct.
 

> But I do not like:
>
>
>1. Having a package just to hold a single type,
>
> Personally, I don't see anything inherently wrong with this. If you *must 
*multiple packages that all need the type, then it should be in a package 
separate from those. In many cases there would be functions that could also 
go in package `state`, but if not, then that's ok too.

2. The consumer package is accepting a concrete type and depends on it - 
> seems this one can not be avoided since there is nothing like structural 
> typing for structs in Go.
>

Your example does feel a bit awkward, but, again, I don't have enough 
information on what is really being achieved to suggest a completely 
different model.  

But I will take a shot in the dark. Think interfaces? Perhaps the 
state.State type returned by Clone() could be an interface? This does not 
solve the problem of having to define the interface in a separate package, 
and I would only use an interface if there was a compelling reason to do 
so. 

Taking a further leap,why "Clone()" at all? What do you do with state.State 
in package consumer? Does it have to be a struct for some reason? If you 
could define a set of functionality that a consumer needs from state.State, 
you could then have Concrete1, Concrete2, and Concrete3 all implement that 
functionality. Then consumer can just use them directly as interfaces ... 
or perhaps that is using them indirectly. Anyway, I hope that is somewhat 
comprehensible. 

Good Luck
 - Jake

On Tuesday, April 24, 2018 at 1:49:45 AM UTC-4, Kaveh Shahbazian wrote:
>
> @Jake @Bryan Thanks!
>
> Current solution I use:
>
> A package that holds the shared data type State:
>
> package state
>
> type State struct {
> Latitude  float64
> Longitude float64
> Mark  string
> Name  string
> // ...
> }
>
> Three packages with different implementations and algorithms:
>
> package concrete1
>
> import (
> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
> )
>
> type Concrete1 struct{}
>
> func (c *Concrete1) Clone() (*state.State, error) { panic("N/A") }
>
> And:
>
> package concrete2
>
> import (
> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
> )
>
> type Concrete2 struct{}
>
> func (c *Concrete2) Clone() (*state.State, error) { panic("N/A") }
>
> And:
>
> package concrete3
>
> import (
> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
> )
>
> type Concrete3 struct{}
>
> func (c *Concrete3) Clone() (*state.State, error) { panic("N/A") }
>
> And the consumer package, which will be given a concrete implementation 
> based on some logic (this is where "Accepting interfaces" is happening):
>
> package consumer
>
> import (
> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
> )
>
> func Use(cln cloner) {}
>
> type cloner interface {
> Clone() (*state.State, error)
> }
>
> The part in question is the *state.State data type. This is the best I 
> could come up with.
>
> But I do not like:
>
>
>1. Having a package just to hold a single type,
>2. The consumer package is accepting a concrete type and depends on it 
>- seems this one can not be avoided since there is nothing like structural 
>typing for structs in Go.
>
>
> There might be a better way to do this.
>

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

Re: [go-nuts] FR: godoc have Methods collapsed by default

[Dan Kortschak]

I like being able to look for methods, so I would be sad to see this as
the default behaviour.

On Thu, 2018-04-26 at 16:00 -0700, swufy via golang-nuts wrote:
> Are there any counter-arguments for why we wouldn't want this for the
> docs?

-- 
You received this message because you are subscribed to the Google 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: Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[David Collier-Brown]

I also ran into a race diagnostic  when I did an "Add" after my main 
programs started "Wait"ing: I moved the add to the main program and cured 
it.

I read this as the WaitGroup being careful and efficient about use of 
locking primitives, and not liking the expensive operation of incrementing 
a semaphore-like construct while someone is waiting for it to change 
towards zero. 

Logically, it's easy to prove correctness of a counter that increments to a 
value and then decrements to zero, and less easy to deal with one that 
jumps up and down (and maybe waves its arms in time with the music (;-))

--dave

-- 
You received this message because you are subscribed to the Google 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: Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[David Collier-Brown]

I also ran into a race diagnostic  when I did and Add after my main 
programs started Waiting: I move the add to the main program and cured it.

I read this as the WaitGroup being careful and efficient about use of 
locking primitives, and not liking the expensive operation of incrementing 
a semaphore-like construct while someone is waiting for it to change 
towards zero. 

Logically, it's easy to prove correctness of a counter that increments to a 
value and then decrements to zero, and less easy to deal with one that 
jumps up and down (and maybe waves its arms in time with the music (;-))


>>

-- 
You received this message because you are subscribed to the Google 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] FR: godoc have Methods collapsed by default

[swufy via golang-nuts]

Feature Request - Have methods for structs to be collapsed by default (with 
an arrow next to the type def to reveal them) in the Index section of 
godocs.

Reasoning: Some packages include multiple structs with methods. For 
example, https://golang.org/pkg/math/big/ has Accuracy, ErrNaN, Float, Int, 
Rat, and RoundingMode with the Float, Int, Rat types have many methods. If 
the methods were collapsed by default, I could click to expand the Int type 
to look for the method I'm looking up. This is particularly useful for 
protos that define RPC endpoints. I'm currently working with a proto that 
defines 21 Request/Response protos where each has at least 10 methods 
associated with them. When I'm looking at that godoc, there's really only 
one struct that I want to look at. The major sections (Overview, Index, 
etc) already have an arrow to collapse the section.

Currently:
type Accuracy func (i 
Accuracy) String() string 
type 
ErrNaN func (err ErrNaN) 
Error() string type Float 
func NewFloat(x float64) *Float 
func ParseFloat(s string, 
base int, prec uint, mode RoundingMode) (f *Float, b int, err error) 
func (z *Float) Abs(x 
*Float) *Float func (x 
*Float) Acc() Accuracy func 
(z *Float) Add(x, y *Float) *Float 
func (x *Float) Append(buf 
[]byte, fmt byte, prec int) []byte 
func (x *Float) Cmp(y 
*Float) int func (z *Float) 
Copy(x *Float) *Float func 
(x *Float) Float32() (float32, Accuracy) 
func (x *Float) 
Float64() (float64, Accuracy) 
...
Request (click the arrow to expand the method list):type Accuracy 
  >type ErrNaN 
  >type Float 
  >type Int 
  >
type Rat   >
type RoundingMode   >type 
Word 

Are there any counter-arguments for why we wouldn't want this for the docs?

-- 
You received this message because you are subscribed to the Google 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] Article: Go for art

[matthewjuran]

Hello,

Here’s an article I’ve written about Go: https://github.com/pciet/goforart

“Go for art. An article about the Go programming language and greater 
professional software community.”

I wrote this today but there is a lot of research built into it. There is 
discussion about religion, and you might consider the article U.S.A. 
propaganda. I try to keep those out of my emails here. For some people this 
might be a good introduction to computer programming or the online Go 
community.

I’m happy to discuss any points although maybe the points about Go are the 
most appropriate.

Thanks,
Matt

-- 
You received this message because you are subscribed to the Google 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: Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[deleplace2015]

Hello Jon
I think this is working as expected. 
The relevant part of the doc is "calls with a positive delta that start 
when the counter is greater than zero, may happen at any time".

This is what happens in your code (stdout on the left, my comments on the 
right)

*  here wg is created, its counter is 0*
*  here after first Add, counter is now 1*
waiting
*  ...here the first child goroutine is sleeping for 1s...*
adding from top level goroutine
*  here after second Add, counter is now 2*
done from top level goroutine
*  here after Done, counter is now 1*
done from background goroutine
*  here after Done, counter is now 0*

There are 3 goroutines involved, and while a few different interleaving of 
messages are possible, what is important here is that
- the first Add *happens-before* wg.Wait()
- the first Add *happens-before *the second Add
- the second Add *happens-before *the calls to Done, which implies that the 
second Add start when the counter is greater than zero (it is 1)

The part of the doc that you quote "If a WaitGroup is reused..." warns 
against a race condition between a "Wait" and an "Add positive number to a 
zero counter", which is not the case here.
I think it can be rephrased as "make sure all the calls to wg.Wait have 
properly returned (*happen-before) *and then you may start reusing the 
WaitGroup if you wish". 

As a side note, you have correctly spotted that it is legal to pass around 
a pointer to the WaitGroup (as opposed to passing it by value, which would 
be illegal). But in simple cases like this one, it is even more idiomatic 
(and legible) to use it directly from the closures scope 
: https://play.golang.org/p/nF9Am77e4u-

Hope this helps :)
Don't hesitate to ask for details on this topic
Valentin

Le jeudi 26 avril 2018 17:29:26 UTC+2, Jon Bodner a écrit :
>
> Hello,
>
> We were having a discussion at work about passing around references to 
> sync.WaitGroup. I said it was a bad idea, because if a goroutine launched a 
> goroutine of its own and called sync.WaitGroup.Add() after a goroutine 
> called sync.WaitGroup.Wait(), but before the count dropped to 0, your code 
> would panic. The comments seem to support this: 
>
> "If a WaitGroup is reused to wait for several independent sets of events, 
> new Add calls must happen after all previous Wait calls have returned."
>
> And the WaitGroup source code for Add has lines like this:
>
> if w != 0 && delta > 0 && v == int32(delta) {
> panic("sync: WaitGroup misuse: Add called concurrently with Wait")
> }
>
> But a co-worker wrote this code, and it runs without a panic: 
> https://play.golang.org/p/NjqK_YoqHeH
>
> I thought that this code might only be working because the playground is 
> single-threaded, but when this code is run locally, it also completes 
> without panics. Running it with the race flag also works properly.
>
> How do you trigger those panics in the WaitGroup codebase?
>
> Thanks,
>
> Jon
>
>

-- 
You received this message because you are subscribed to the Google 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] Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[Ian Lance Taylor]

On Thu, Apr 26, 2018 at 8:29 AM, Jon Bodner  wrote:
>
> We were having a discussion at work about passing around references to
> sync.WaitGroup. I said it was a bad idea, because if a goroutine launched a
> goroutine of its own and called sync.WaitGroup.Add() after a goroutine
> called sync.WaitGroup.Wait(), but before the count dropped to 0, your code
> would panic. The comments seem to support this:
>
> "If a WaitGroup is reused to wait for several independent sets of events,
> new Add calls must happen after all previous Wait calls have returned."
>
> And the WaitGroup source code for Add has lines like this:
>
> if w != 0 && delta > 0 && v == int32(delta) {
> panic("sync: WaitGroup misuse: Add called concurrently with Wait")
> }
>
> But a co-worker wrote this code, and it runs without a panic:
> https://play.golang.org/p/NjqK_YoqHeH
>
> I thought that this code might only be working because the playground is
> single-threaded, but when this code is run locally, it also completes
> without panics. Running it with the race flag also works properly.
>
> How do you trigger those panics in the WaitGroup codebase?

Here's one panic:

package main

import (
"sync"
"time"
)

func main() {
var wg sync.WaitGroup
wg.Add(1)
go func() {
time.Sleep(time.Millisecond)
wg.Add(-1)
wg.Add(1)
}()
wg.Wait()
}

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] float accuracy when calculating Fibonacci numbers

[Ian Lance Taylor]

On Thu, Apr 26, 2018 at 1:17 AM, Yuval Lifshitz  wrote:
>
> I ran into the following issue when started playing with go. Had the
> following small program to calculate Fibonacci numbers using the closed
> form:
>
> package "fib"
>
> import "math"
>
> var sqrt_5 = math.Sqrt(5.0)
> var psi = -1.0/math.Phi
>
> // had to add this to solve accuracy issue
> func round(x float64) uint64 {
> return uint64(math.Floor(x + 0.5))
> }
>
> // find the nth fibonacci number based on Binet's formula
> // see here:
> https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
> func fibonacci(n uint) uint64 {
> float_n := float64(n)
> return round((math.Pow(math.Phi, float_n) - math.Pow(psi,
> float_n))/sqrt_5)
> }
>
>
> When I first tried without doing the "rounding" I did not get whole numbers
> as the output (similar program in C++ gave whole numbers without rounding).
> Following test is failing without the call to "round()":
>
> package "fib"
>
> import "testing"
>
> var results = map[uint]uint64 {
> 0: 0,
> 2: 1,
> 10: 55,
> 14: 377,
> 20: 6765,
> 29: 514229,
> 33: 3524578,
> 59: 956722026041,
> }
>
> func Test_fibonacci(t *testing.T) {
> for arg, expected := range results {
> actual := fibonacci(arg)
> if actual != expected {
> t.Error("Expected", expected, "got", actual)
> }
> }
> }
>
>
>
> Are there known accuracy issues with floating points in go?

No.

I suggest that you show us your C code.  Thanks.

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] How does time reported by go test relate to the wall clock time?

[Jan Mercl]

time reports build+test time, but go test reports only test time.

On Thu, Apr 26, 2018, 18:54 Prateek Rungta  wrote:

> I've noticed weird discrepancies in the time reported by `go test
> `, and the elapsed wall clock time.
>
> For example:
>
> ❯ time go test ./client
> ok   github.com/m3db/m3db/client *11.717s*
> /Users/prungta/code/go1.9.2/bin/go test ./client  *10.54s* user 1.58s
> system 74% cpu 16.233 total
>
> ❯ time go test ./storage
> ok   github.com/m3db/m3db/storage *4.830s*
> /Users/prungta/code/go1.9.2/bin/go test ./storage * 10.19s *user 1.49s
> system 107% cpu 10.860 total
>
>
> How does `go test` calculate the time it reports?
>
> --
> You received this message because you are subscribed to the Google 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.
>
-- 

-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: Using variadic function / context in an interface?

['simon place' via golang-nuts]

does the init NEED to be in the interface?

On Thursday, 26 April 2018 17:55:07 UTC+1, Nimrod Shneor wrote:
>
> Hey everyone,
> I've encountered a design issue - 
> I have an the following interface -
>
> type Runner interface {
>   Run(x X,y Y)
> }
>
> I want to add to it an Init(...) method which will initialize the internal 
> fields of the Runner before performing `Run`..
> My issue is that different structs implementing the `Runner` interface 
> require different fields in order to initialize, How should I solve this?
>
> Thanks a lot!
> Nimrod.
>

-- 
You received this message because you are subscribed to the Google 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 does time reported by go test relate to the wall clock time?

[Prateek Rungta]

I've noticed weird discrepancies in the time reported by `go test 
`, and the elapsed wall clock time. 

For example: 

❯ time go test ./client
ok   github.com/m3db/m3db/client *11.717s*
/Users/prungta/code/go1.9.2/bin/go test ./client  *10.54s* user 1.58s 
system 74% cpu 16.233 total

❯ time go test ./storage
ok   github.com/m3db/m3db/storage *4.830s*
/Users/prungta/code/go1.9.2/bin/go test ./storage * 10.19s *user 1.49s 
system 107% cpu 10.860 total


How does `go test` calculate the time it reports?

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

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

[kevthemusician]

Could you explain what you mean by just passing binary data? 

I am currently trying to build an SDK using Golang mobile, and it's a bit 
frustrating with all of the binding issues


Thanks,

Kev

On Saturday, 10 March 2018 20:10:01 UTC, Ged Wed wrote:
>
> Some large logging and metrics companies provide gomobile based packages. 
> The packages are used by other making gomobile systems
>
>
> https://logpacker.com/blog/gomobile-library-development-for-ios-and-android
>
>
> https://github.com/logpacker/mobile-sdk
>
> Admittedly it's rather old now.
>
> Boltdb works on mobile and is supported.
>
> Caddy works on mobile and is supported.
>
> I have used it for a few projects and it's been sturdy.
>
> The binding issues are easy to get around if you just pass binary data. 
> Some use protobufs. Admittedly it's a crude work around by not too horrible
>
>

-- 
You received this message because you are subscribed to the Google 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] float accuracy when calculating Fibonacci numbers

[Yuval Lifshitz]

Dear community,
I ran into the following issue when started playing with go. Had the 
following small program to calculate Fibonacci numbers using the closed 
form:

package "fib"

import "math"

var sqrt_5 = math.Sqrt(5.0)
var psi = -1.0/math.Phi

// had to add this to solve accuracy issue
func round(x float64) uint64 {
return uint64(math.Floor(x + 0.5))
}

// find the nth fibonacci number based on Binet's formula
// see here: 
https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
func fibonacci(n uint) uint64 {
float_n := float64(n)
return round((math.Pow(math.Phi, float_n) - math.Pow(psi, float_n))/
sqrt_5)
}


When I first tried without doing the "rounding" I did not get whole numbers 
as the output (similar program in C++ gave whole numbers without rounding).
Following test is failing without the call to "round()":

package "fib"

import "testing"

var results = map[uint]uint64 {
0: 0,
2: 1,
10: 55,
14: 377,
20: 6765,
29: 514229,
33: 3524578,
59: 956722026041,
}

func Test_fibonacci(t *testing.T) {
for arg, expected := range results {
actual := fibonacci(arg)
if actual != expected {
t.Error("Expected", expected, "got", actual)
}
}
}



Are there known accuracy issues with floating points in go?

-- 
You received this message because you are subscribed to the Google 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] Using variadic function / context in an interface?

[nimrodshn]

Hey everyone,
I've encountered a design issue - 
I have an the following interface -

type Runner interface {
  Run(x X,y Y)
}

I want to add to it an Init(...) method which will initialize the internal 
fields of the Runner before performing `Run`..
My issue is that different structs implementing the `Runner` interface 
require different fields in order to initialize, How should I solve this?

Thanks a lot!
Nimrod.

-- 
You received this message because you are subscribed to the Google 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: Extension for type assertion of interface array

['simon place' via golang-nuts]

i too didn't like this, although i get the reasons for it.

but for me these are unaddressed points;

1. the language does not distinguish array types, as a group, in any way, 
except here.
2. you can have many types that simultaneously implement multiple 
interfaces, for these you need copying code for every COMBINATION.
3. interfaces are commonly used by libraries, library users providing the 
implementations, this makes its impossible to provide the copying in the 
library, and makes the use of arrays of interfaces much less friendly.

it does seem like some generics should improve this situation.

-- 
You received this message because you are subscribed to the Google 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] Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[Jon Bodner]

Hello,

We were having a discussion at work about passing around references to 
sync.WaitGroup. I said it was a bad idea, because if a goroutine launched a 
goroutine of its own and called sync.WaitGroup.Add() after a goroutine 
called sync.WaitGroup.Wait(), but before the count dropped to 0, your code 
would panic. The comments seem to support this: 

"If a WaitGroup is reused to wait for several independent sets of events, 
new Add calls must happen after all previous Wait calls have returned."

And the WaitGroup source code for Add has lines like this:

if w != 0 && delta > 0 && v == int32(delta) {
panic("sync: WaitGroup misuse: Add called concurrently with Wait")
}

But a co-worker wrote this code, and it runs without a 
panic: https://play.golang.org/p/NjqK_YoqHeH

I thought that this code might only be working because the playground is 
single-threaded, but when this code is run locally, it also completes 
without panics. Running it with the race flag also works properly.

How do you trigger those panics in the WaitGroup codebase?

Thanks,

Jon

-- 
You received this message because you are subscribed to the Google 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] Extension for type assertion of interface array

[Alex Efros]

Hi!

On Sun, Apr 22, 2018 at 09:48:13PM -0700, nsakth...@gmail.com wrote:
> this pattern requires a language level change to avoid unwanted array copy 
[...]
> but shouldn't the language provide an extension to already available syntax

The language is trying to avoid hiding performance-critical things (like
copying an array) by nice syntax. You're supposed to always write such
code (like copy an array) manually, to make it clear what's happens.

To be clear, I'm not arguing this is good idea… but AFAIK it's official
position about such ideas… and it makes some sense.

-- 
WBR, Alex.

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

[go-nuts] [ANN] A utility lib make it easy to write gnatsd proxy and middlewares

[antmanler]

gnatsd-gw  
https://github.com/antmanler/gnatsd-gw

A utility lib make it easy to write gnatsd proxy and middlewares

It uses the same code as gnatsd to parse protocol, can inspect most 
commands.

Features:

   - Leverage the official zero-alloc parser to handle connections
   - Can inspect most commands in nats proto
   - TCP & Websocket gateway
   - Embeded as a library
   

Inspired by

   -  nats-websocket-gw A websocket to NATS gateway
   -  websocket-nats An in-browser websocket client for NATS
   

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