Why should I have written ZeroMQ in C, not C++ (2012)
1–10 of 147 posts
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#2Re: Why should I have written ZeroMQ in C, not C++ (2012)
#3Earlier comments: https://news.ycombinator.com/item?id=6220049 https://news.ycombinator.com/item?id=3953434
And comments to part II (http://www.250bpm.com/blog:8):
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#4This actually sounds like an argument for why he should've used a smaller subset (or different) of C++.
For example: make all constructors private and empty and use public static factory methods for manufacturing new instances. Now the factory can fail, and return an error to boot.
Similarly, ditch C++ exceptions and introduce the notion of a status object that methods return. You always have the option of C-style semantics without dumping the genuine advantages C++ brings.
In terms of some of what is brought up in part II, a C++ engineer can (and would) implement linked-lists C-style. See: http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive/list...
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#5Sometime in the future:
"Why I should have written nanomsg in Rust, not C".
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#6This might be unrelated, but after reading this 3 years after publication I think that Go approach to error handling i so much better because of exactly the same simplicyty as C.
( If you dont’t understand why, dont’t worry it will be obvious to you in 3 years :-)
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#7Interesting article. So, more confirmation C++ is inferior for writing predictable or high performance applications. I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game. Zero-cost abstractions plus solving C++'s specific problems, painless C FFI, and compilation to C (or LLVM) to leverage their compilers. Might make a nice combo. I doubt we'll see much takeup, though, as the technical merits rarely dictate that.
On a related note, I'd like to see the results of it being coded in a modern Ada or SPARK with one of the best compilers. I'd be interested in seeing it with full runtime checks on and off with conservative optimization. ZeroMQ with strong implementation assurance could lay the foundation for all kinds of secure networking and middleware schemes. Heck, I'd like to see a team formally verify a version of it with an executable for common architectures. I'd have fun with that. :)
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#8Sometime in the future: "Why I should have written nanomsg in Rust, not C".
If you read part II (the link to it is near the end of the post), you see that one of the things he wanted was intrusive linked lists.
From what I have read so far, implementing intrusive lists is not easy in Rust. (If you know of a working intrusive doubly linked list implementation in Rust 1.0 that does not invoke undefined behavior, please tell me; I'd like to know how it should be done.)
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#9Interesting article. So, more confirmation C++ is inferior for writing predictable or high performance applications. I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game. Zero-cost abstractions plus solving C++'s specific problems, painless C FFI, and compilation to C (or LLVM) to leverage their compilers. Might make a nice combo. I doubt we'll see much t…
>I actually see an opportunity for a C-compatible or C-competitive systems language here to beat C++ at its own game.
Go or Rust? They might not quite match your dream outlined above, but I think in practice they are pretty much used with the purpose of achieving something similar. They both can be "unsafe" as needed and integrate well with C and ASM.
Re: Why should I have written ZeroMQ in C, not C++ (2012)
#10Sometime in the future: "Why I should have written nanomsg in Rust, not C".
If you read part II (the link to it is near the end of the post), you see that one of the things he wanted was intrusive linked lists. From what I have read so far, implementing intrusive lists is not easy in Rust. (If you know of a working intrusive doubly linked list implementation in Rust 1.0 that does not invoke undefined behavior, please tell me; I'd like to know how it should be done.)
Do you mean "unsafe" instead of "undefined"?
Here's what I found after a Google search, by one of the core Rust devs (unsurprisingly).