Why should I have written ZeroMQ in C, not C++ (2012)
1–10 of 170 posts
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#2I'm a bit confused about the current state of ZeroMQ and its relatives. There's nanomessage, which for some reason didn't pan out and is superseded by nng(?), but ZMQ still seem to be the most popular option. If I were to pick a broker-less message queue today, what should I pick?
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#3I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: object-oriented programming as a language design is not. Once you understand what encapsulation, inheritance and polymorphism are, you're much better off using them as guidance to structure your program in an otherwise procedural language like C than wrestling with a few dozen new keywords and an opaque specification.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#4I'm a bit confused about the current state of ZeroMQ and its relatives. There's nanomessage, which for some reason didn't pan out and is superseded by nng(?), but ZMQ still seem to be the most popular option. If I were to pick a broker-less message queue today, what should I pick?
I'm planning on using core NATS (as opposed to NATS streaming) for a lot of my message queuing. A brokered message queue is the same as a brokerless message queue where message forwarding (brokering) is not performed...
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#5I'm a bit confused about the current state of ZeroMQ and its relatives. There's nanomessage, which for some reason didn't pan out and is superseded by nng(?), but ZMQ still seem to be the most popular option. If I were to pick a broker-less message queue today, what should I pick?
My understanding: Pick zmq if you want something safe and battle-tested with good client library support. Pick nng if you want to be at the forefront of new tech or need some of its unique features over zmq (https://nanomsg.org/documentation-zeromq.html). Performance-wise nng still seems like it's inferior to zmq because it's not as heavily optimized. There are lots of performance-related unresolved Github issues.
nanomsg is not an option because it's essentially abandoned.
I've been using nng for a project of mine and I'm happy with it so far.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#6It seems like the author's main complaints are avoided if one follows the Google C++ style guide, which says:
- Don't use C++ exceptions
- Don't do work in constructors (prefer "Init" or factory functions instead)
https://google.github.io/styleguide/cppguide.html
There may be other reasons to prefer C over C++, but if you don't like exceptions, you don't have to use them.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#7When I did C++ I always ended up using a very small subset of it. No exceptions, no inheritance besides a few interfaces. But in general I agree with his point. There are a few things C could improve though.
One would be a way to automatically clean up resources. Maybe something like “defer” in Go.
I wonder if templates would fit into C. STL is super useful.
A real string type would be good too.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#8I'm a bit confused about the current state of ZeroMQ and its relatives. There's nanomessage, which for some reason didn't pan out and is superseded by nng(?), but ZMQ still seem to be the most popular option. If I were to pick a broker-less message queue today, what should I pick?
My understanding: Pick zmq if you want something safe and battle-tested with good client library support. Pick nng if you want to be at the forefront of new tech or need some of its unique features over zmq ( https://nanomsg.org/documentation-zeromq.html ). Performance-wise nng still seems like it's inferior to zmq because it's not as heavily optimized. There are lots of performance-related unresolved Github issues.…
Would you say either is something you would put in a decently scaled production system?
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#9It seems like the author's main complaints are avoided if one follows the Google C++ style guide, which says: - Don't use C++ exceptions - Don't do work in constructors (prefer "Init" or factory functions instead) https://google.github.io/styleguide/cppguide.html There may be other reasons to prefer C over C++, but if you don't like exceptions, you don't have to use them.
“prefer "Init" or factory functions instead“
I vote for factory functions. They bring you pretty close to how C would do it.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#10I've always felt that object-oriented programming as a concept (that is, define structures and then define functions to operate on them together) is useful: object-oriented programming as a language design is not. Once you understand what encapsulation, inheritance and polymorphism are , you're much better off using them as guidance to structure your program in an otherwise procedural language like C than wrestling w…
I use C++ for decades, but I used it always for the projects that were supposed to last long. With that limitation, I've constantly avoided two things:
1) dependence on external C++ libraries, especially boost.
2) trying to always have the code using the latest changes in the standard proposals or the standards.
With these two limitations, and a lot of additional internal "practices" it's possible to maintain a long-running C++ project without doing what I consider "wrong" stuff.
Note: I grew up on assembly, so I was always biased by considering what the optimal code should be as presented to the CPU, after the compilation.
The smaller the project and the environment around the project is, these my preferences could be relaxed. There are surely use cases where "anything could go." But then, the question is always, why not something "more convenient" than both C and C++?
But now I also almost think that if I would be forced to reduce these my "hard projects" "rules and practices" to a minimum number of words, I would probably state it "only C allowed."