Add an example ZMQ client in the spirit of the existing contrib/zmq/zmq_sub.py, but in golang. As a bonus, this also demonstrates how to do RPC.
Maybe controversially, this depends on btcd for serialization and RPC. Given this is just example code, the use of btcd doesn't seem too heinous to me.
I'm sure this is useful to people that want to use zmq from golang, but I don't think the core repository is a good place to have examples for every programming language, sorry.
(we don't have RPC bindings for other languages than Python in the repo either, and the Python one exists only because we actively use Python for the tests)
so NACK from me
NACK too, not the right place — also think contrib/zmq/zmq_sub.py could be removed. @laanwj how about one repo in bitcoin-core org to hold these examples, like bitcoin-core/examples or bitcoin-core/contrib? This way that repo could have CI to keep the examples working with latest version?
how about one repo in bitcoin-core org to hold these examples, like bitcoin-core/examples or bitcoin-core/contrib?
Seems reasonable to me. Concept ACK a separate bitcoin-core repo.
Do we really want to maintain yet another repo with examples in code written in languages that are not commonly used in the Bitcoin Core project. I don't see how this could be a successful repo with no review and potentially no interest. What speaks against putting this up as a GitHub gist or personal GitHub repo? This way it can still be found by a search engine, but doesn't add a burden to the Bitcoin Core project.
95 | + 96 | + for { 97 | + select { 98 | + case msg := <-newmsg: 99 | + msgType := string(msg[0]) 100 | + encoded := hex.EncodeToString(msg[1])
Seems strange that you would need to encode payloads as hex strings here, instead of just passing the data directly. Is the concern 0 bytes? https://golang.org/pkg/builtin/#string seems to indicate that arbitrary byte values are fine.
utACK 870178bfb6cf36191cfd1f54854639bd8e1adc64
The contrib/ directory is kind of crowded and disorganized at this point, but I think it'd be great to have a contrib/examples/ directory with minimal examples of reasonable best practices for accessing bitcoind from different languages and interfaces. Gists and stackoverflow posts are no substitute for a nice collection of examples because they get out of date and code quality in these places is often terrible.
I'm not sure if the objections above are about more about maintenance burden or review burden. Review burden could be alleviated by tagging example PRs so developers who aren't interested in them can ignore them. Maintenance burden could be alleviated by just having a policy of deleting any example that gets out of date unless someone steps up to fix it.
@laanwj how about one repo in bitcoin-core org to hold these examples, like bitcoin-core/examples or bitcoin-core/contrib? This way that repo could have CI to keep the examples working with latest version?
I'd say "put it on your own blog". Or a wiki. There's no need to centralize everything. But if you really volunteer on maintaining that, why not... I don't.
I'm not sure if the objections above are about more about maintenance burden or review burden.
Both! if you noticed, we have 285 PRs open and are struggling. I'm trying really hard to keep the scope of this project down to necessities. Sorry.
The best place for Go language bindings would be in the go package repository, I suppose.
Gists and stackoverflow posts are no substitute for a nice collection of examples because they get out of date and code quality in these places is often terrible.
This is exactly the same, or even worse, if you'd dump it in a directory here. It won't get tested in the CI, so it will code rot, most of us don't know (or don't have to time to go about) maintaining go code.
Happy to close and post in a personal repo. Thanks for thoughts, all.
Happy to close and post in a personal repo. Thanks for thoughts, all.
I'm sorry to be so negative about this, it's great that you're trying to contribute, it's just, not clear to organize this for many languages, and at least personally I'm drowning in maintenance burden.
@laanwj don't worry at all - I'm not discouraged. The concerns are completely reasonable, and I sympathize with the load maintainers and reviewers are under. A closed PR at least makes the code marginally googleable if anyone's looking for something like this :smile:.