The readme page shows usage that won't work if an user tries it out

[aricart]

See https://github.com/nats-io/nats.js/issues/344

While the API is shown correctly, the ordering is not. So copy-paste will not result in what the user may be expecting by reading the sample code illustrating the API.

// Connect to a server
nc, _ := nats.Connect(nats.DefaultURL)

// Simple Publisher
nc.Publish("foo", []byte("Hello World"))

// Simple Async Subscriber
nc.Subscribe("foo", func(m *nats.Msg) {
    fmt.Printf("Received a message: %s\n", string(m.Data))
})

[kozlovic]

I understand, but this is not to be an example but show how to use the APIs. Either we completely remove those, or really code separate them (that is, shown as code for individual API calls). But in that list of APIs calls, moving those 2 around may "make it work", but what about the others, drain, unsubscribe, etc..

[aricart]

Exactly - the point is that users are looking at it not as an illustration of what the API call is doing, but rather as some coherent program which was never the intention - I agree with you 100% - I have always looked at the README examples simply as an outline of the logic, which presumes, you are going to do things in the right order.

[ripienaar]

We need an agreed upon set of patterns and implement full - but basic - actual working programs in each language we support.

Readme’s never do programming APIs justice ime

[kozlovic]

Each library that we support I would assume have a directory with some examples. The README here is supposed to show how to use a given API (for instance number of parameters, how they look like, etc..). But maybe we don't need in Go and other if they exist in nats.io doc?

[j0holo]

Maybe we could point out in the README too the examples for actual working programs. The README gives more of a feel how this package could be used and what it offers, right?