The "message-bus" import is eliminated when ran from play.golang.org, as it doesn't match the package name as used by the code. It needs to be aliases, as in https://play.golang.org/p/U5nstd936qf

I like the new interface. Really, I used the semaphore to control concurrency outside the bus. And, I hope to keeps both the old interface and the new interface.

• There is the code that depends on the old interface.
• The new interface has a concern as performance is degraded. https://github.com/vardius/message-bus/blob/master/README.md#benchmark

v1.0.0 https://github.com/vardius/message-bus/blob/c1f01b61c37e8992775c53d6be6b61e362adfce2/bus.go#L82

v1.1.0 https://github.com/vardius/message-bus/blob/bdb2394d9af1cf4f226490d32a6cb4e8f6d36ab7/bus.go#L93

Ref: https://github.com/vardius/message-bus/commit/dd40db9f8e8a2cfe434fdc9381202827f851c931#diff-ecf9c6bcdc8d97b7f04226e8857c1108L82

Your FOSSA integration was successful! Attached in this PR is a badge and license report to track scan status in your README.

Below are docs for integrating FOSSA license checks into your CI:

• CircleCI
• TravisCI
• Jenkins
• Other

I merged it https://github.com/vardius/message-bus/pull/6 but have to think about it if this is an improvement or not, it increases allocations number plus if the number of subscribers is high it actually slows down

before

BenchmarkPublish-4                   	 5214352	       226 ns/op	       0 B/op	       0 allocs/op
BenchmarkSubscribe-4                 	  632084	      3319 ns/op	     730 B/op	       5 allocs/op
Benchmark1Subscriber1Topic-4         	 5545311	       225 ns/op	       0 B/op	       0 allocs/op
Benchmark1Subscriber100Topics-4      	 2261838	       808 ns/op	       0 B/op	       0 allocs/op
Benchmark100Subscribers1Topic-4      	   61615	     19539 ns/op	       0 B/op	       0 allocs/op
Benchmark100Subscribers100Topics-4   	   60561	     34031 ns/op	       0 B/op	       0 allocs/op

after

BenchmarkPublish-4                   	  598759	      1981 ns/op	       2 B/op	       0 allocs/op
BenchmarkSubscribe-4                 	 1000000	      4218 ns/op	     725 B/op	       4 allocs/op
Benchmark1Subscriber1Topic-4         	  629875	      1899 ns/op	      13 B/op	       0 allocs/op
Benchmark1Subscriber100Topics-4      	  621306	      1935 ns/op	       0 B/op	       0 allocs/op
Benchmark100Subscribers1Topic-4      	    6942	    206815 ns/op	    3343 B/op	       8 allocs/op
Benchmark100Subscribers100Topics-4   	    6996	    320923 ns/op	    8107 B/op	      16 allocs/op

Originally posted by @vardius in https://github.com/vardius/message-bus/pull/6#issuecomment-651752332

Did not release new version yet, will think about it and either revert or release would love to hear second opinion about it.

	go func() {
 		for args := range h.queue {
- 			h.callback.Call(args)
+		 	go func(targs []reflect.Value) {
+ 				h.callback.Call(targs)
+ 			}(args)
 		}
 	}()

Personally I think it is up to a developer of a handler to execute his callback in a goroutine or not, up to him and the package itself should not enforce goroutine here. cc @me020523

How does this library compare with the usage of systems like Kafka and RabbitMQ as message transporters? Particularly in terms of performance and security.

Edit: just took a look at the code, it seems like this library doesn't do what I thought. So is it accurate to say that it's a sync RWMutex wrapper utility? How can one use it to establish connection between microservices, if at all possible?