wallyqs

Bluesky's project name is 'Jetstream' and NATS.io persistence engine is `JetStream` (camel case), which can be confusing but name not exactly the same.

- NATS JetStream docs: https://docs.nats.io/nats-concepts/jetstream

- Bluesky's 'Introducing Jetstream': https://docs.bsky.app/blog/jetstream

Dhall has a lot of really cool ideas, it would be great to have semantic integrity checks on imports in other languages too.

Put out an example of using it to switch the transport so that it is over NATS instead, this works now thanks to the interop with net/http package: https://github.com/wallyqs/connect-go/commit/2e744ec4bf7ce31... Internally requests are treated as NATS requests so you would get similar performance and latency as when using core NATS request/response.

NATS has a similar protocol to Redis and optimized for this use cause of doing pub/sub based low latency Request/Response instead of HTTP. The payload is opaque so you can use msgpack if needed, and the protocol also supports sending headers now: https://docs.nats.io/nats-protocol/nats-protocol#protocol-me...

(disclaimer: I'm one of the NATS maintainers :) )

It has gotten much better but in our project we got bitten by this. I gave a talk about it at GoSF last year if looking for some Go v2 modules schadenfreude :) https://www.youtube.com/watch?v=8xAaZDSDWOc

For speed, NATS.io also has RPC semantics and protocol is fairly straightforward like Redis: https://docs.nats.io/developing-with-nats/sending/request_re... || https://docs.nats.io/nats-protocol/nats-protocol

I'm one of the NATS maintainers though have been using the project for several years. Most of the community is more active in the Slack channel: https://slack.nats.io/