Thanks! The spec can be found here: https://github.com/bloomberg/blazingmq/tree/main/etc/tlaplus

Some of your questions might be answered in the accompanying blog - https://www.bloomberg.com/company/stories/bloomberg-publishe..., and the comparison doc https://bloomberg.github.io/blazingmq/docs/introduction/comp....

Python client library is coming in a few weeks.

Great. I also hope .Net. Erlang (Elixir) would be also very useful. Hard to doubt many would appreciate Node.JS. I would also cheer Common Lisp, Guile and Lazarus but I understand these probably are too exotic for Bloomberg to invest in. Whatever, the common denominator is - clients for all sorts of runtimes are expected from such a products. In fact I was very surprised to see such a small client libraries list. Perhaps this is going to get fixed later.

Hi, internally, we have support for JS but through an enterprise layer which cannot be open sourced. The focus so far has been to prioritize client libraries in languages which are dominant internally. I am sure we will see libraries in other languages due to demand as well as external contributions!

Makes sense. Thank you for doing an amazing job and releasing the code!

Thank you!

Hi, one of the authors here.

> In a zero-replication no-leader-election (or all-in-one-node) scenario what is min latency observed?

We saw sub-millisecond latency in this case (typically double-digit microseconds).

Splendid! Great work, guys. And thanks again for sharing. Dockerfile is good way to share build deps.

Thank you!

Hi, one of the authors here. We will be releasing a Python client library in a few weeks.

Hi, one of the authors here. We will be releasing a Python client library in a few weeks.

Any plans to support .NET?

There are a number of ways to wrap native code libraries as a managed library. I did it once (packaged an Obj-C library as a .NET DLL for a Xamarin app) back in 2018 but had lots of help from a teammate who knew that dance far better than me and I forgot all of the details. I googled and found at least four different blogs posts showing how to do it.

I know that's not an answer but if you're feeling adventurous you might be able to help the project.

+1 vote from me for a first-class client for .Net core.

I'd tolerate wrappers for certain things, but not for this thing.

Hi, no plans as of yet. Please also see my response to the Golang client library request above.

Are there plans for a native Golang library? That's the only thing stopping me from looking at this. Many thanks!

It's not on the roadmap for the next 6 months. But priorities can change depending upon the demand. One thing to note is that BlazingMQ client libraries are very stateful, and implementing a batteries included library is a non-trivial effort.

One of the authors here. Thanks for pointing that out. TLA+ spec can be found here -- https://github.com/bloomberg/blazingmq/tree/main/etc/tlaplus.

How is this "deliberately avoiding any formal specification or proof"?

I think they are referring to the specific section below the notice.

Correct

Hi, one of the authors here. BlazingMQ depends on two other open source C++ libraries: https://github.com/bloomberg/bde and https://github.com/bloomberg/ntf-core. I believe documentation writer wanted to highlight that BlazingMQ does not depend on frameworks like ZooKeeper, etc.

Ah, yes, that makes sense! I'm thinking about framework from the wrong angle.

I can definitely see why that's a bonus. So many data pipeline tools, but so many written in Java. It's for that reason that I've always reinvented the wheel. Perhaps I'll check this out...

We have updated the phrasing to make it more clear.