3 ms·

Off topic here but > Carefully architected and written in C++ from the ground up with no dependency on any external framework, BlazingMQ provides… What a weir

Off topic here but > Carefully architected and written in C++ from the ground up with no dependency on any external framework, BlazingMQ provides… What a weird selling point. There are pros and cons to having no dependencies. Not long ago, it was a common decision for C++ projects because dependency management was a mess. But that hasn’t been the case for a long time (arguably we have the opposite problem - there are so many ways of doing it: Conan, vcpkg, bazel, spack, raw cmake, nix, etc) So what would the pros and cons be today and why is it a selling point? For instance, a pro is that everything is bespoke to the task at hand, no hammering square pegs into round holes designed for a slightly different use case. A con is that the entire attack surface is managed by one team. CVEs identified and solved on another project is a pretty good thing when you depend on that project. The main reason I’m surprised, though, is that there are some no-brainer dependencies these days. Fmt, catch2/gtest, metaprogramming libraries, etc.

omeid2 3y ago
Sending patches to fix a project is hard work, sending patches to fix issues in a projects' upstream projects is even harder. This alone is an important point to avoid dependencies, specially if you're anything like Bloomberg.
- i-use-nixos-btw 3y ago
  I run into that problem a lot, to be fair. Though my approach is to fork and maintain the fork until my PR is accepted, merged, and in a tagged release. Another is to apply a diff to the dependency within the build system, which is what I do a lot in Nix (mainly to solve cmake issues on hermetic builds). Either way, it isn't unsurmountable. It doesn't really matter so much if it's used as an executable rather than as a library, though in the case of the latter it's really handy to be able to e.g. pass a custom spdlog sink for logging.
deleted 3y ago
[deleted]
callbacker 3y ago
Hi, one of the authors here. BlazingMQ depends on two other open source C++ libraries: https://github.com/bloomberg/bde https://github.com/bloomberg/bde and https://github.com/bloomberg/ntf-core https://github.com/bloomberg/ntf-core. I believe documentation writer wanted to highlight that BlazingMQ does not depend on frameworks like ZooKeeper, etc.
- i-use-nixos-btw 3y ago
  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...
  - callbacker 3y ago
    We have updated the phrasing to make it more clear.
pravus 3y ago
> So what would the pros and cons be today and why is it a selling point? I'm not saying they pulled it off because I would need to evaluate it, but having your own dependency stack can result in a much more streamlined solution for extra performance since you don't have to compromise to someone else's data model. As this is a high speed message bus, it's entirely appropriate. These are also basically application-level network routers which really don't need huge levels of dependencies so to be honest I'd be running away from anything that claims it's written using 1000s of the newest, latest and greatest whatevers. Churning out a faster string grinder is what I'm looking for.

omeid2 3y ago

Sending patches to fix a project is hard work, sending patches to fix issues in a projects' upstream projects is even harder. This alone is an important point to avoid dependencies, specially if you're anything like Bloomberg.

i-use-nixos-btw 3y ago
I run into that problem a lot, to be fair. Though my approach is to fork and maintain the fork until my PR is accepted, merged, and in a tagged release. Another is to apply a diff to the dependency within the build system, which is what I do a lot in Nix (mainly to solve cmake issues on hermetic builds). Either way, it isn't unsurmountable. It doesn't really matter so much if it's used as an executable rather than as a library, though in the case of the latter it's really handy to be able to e.g. pass a custom spdlog sink for logging.

deleted 3y ago

[deleted]

callbacker 3y ago

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

i-use-nixos-btw 3y ago
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...
- callbacker 3y ago
  We have updated the phrasing to make it more clear.

pravus 3y ago

> So what would the pros and cons be today and why is it a selling point? I'm not saying they pulled it off because I would need to evaluate it, but having your own dependency stack can result in a much more streamlined solution for extra performance since you don't have to compromise to someone else's data model. As this is a high speed message bus, it's entirely appropriate. These are also basically application-level network routers which really don't need huge levels of dependencies so to be honest I'd be running away from anything that claims it's written using 1000s of the newest, latest and greatest whatevers. Churning out a faster string grinder is what I'm looking for.