Live data from Hacker News

Why should I have written ZeroMQ in C, not C++ (2012)

250bpm.com

11–20 of 147 posts

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#11
post #6

This 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 :-)

>I think that Go approach to error handling i so much better because of exactly the same simplicyty as C.

Not to mention Go having multiple return values IMHO also takes away the major pain point of returning errors in C; using up your only return value and having to take pointer arguments when you would rather not.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#12
post #8

Sometime 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.)

I have one here: https://github.com/dschatzberg/intrusive

It can be used in a freestanding (nostd) environment such as a kernel. It uses unsafe code but provides a safe interface. The primary technique is to embed the type that is iterated over in a larger struct which contains the links. This way I can give out references to the inner type without fear of invalidating the iterator.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#13
post #6

This 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 :-)

>I think that Go approach to error handling i so much better because of exactly the same simplicyty as C. Not to mention Go having multiple return values IMHO also takes away the major pain point of returning errors in C; using up your only return value and having to take pointer arguments when you would rather not.

Multiple return values is now handled in C++ with tuples and std::tie.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#14
post #4

This 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 se…

And so I will continue to avoid C++ because I'm not a master and will not avoid the many pitfals, and I want to get things done, not become a master of C++.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#15
post #6

This 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 :-)

yeah go/rust error handling is great. Much better than exceptions which make the code hard to read since you can't easily predict where is the flow going to jump. And the multiple-return is very convenient in this case too.

Also, with Go's approach you have to either explicitly ignore the error or deal with it.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#16
post #4

This 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 se…

And so I will continue to avoid C++ because I'm not a master and will not avoid the many pitfals, and I want to get things done, not become a master of C++.

What a strange language, that so much sage wisdom involves what parts of it you shouldn't use. (Former C++ programmer, a long time ago, before the "don't use these parts" advice became a thing.)

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#18

Interesting 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.

Vala gets no love in these discussions; a C# subset that compiles to C and gobject.

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#19
post #16

Earlier quoted context omitted.

And so I will continue to avoid C++ because I'm not a master and will not avoid the many pitfals, and I want to get things done, not become a master of C++.

What a strange language, that so much sage wisdom involves what parts of it you shouldn't use. (Former C++ programmer, a long time ago, before the "don't use these parts" advice became a thing.)

There was a post here recently, explaining type systems are effectively about restricting you from encoding nonsensical constructions. C is ASM with the ability to encode some nonsensical ASM instruction-sequences removed, etc.

The weird thing about C++—and the reason it didn't just absorb/replace C—is that it gives you the ability to encode strictly more nonsensical things than C does. In that sense, C looks more like the descendant of C++ than the other way around!

Re: Why should I have written ZeroMQ in C, not C++ (2012)

#20
post #16

Earlier quoted context omitted.

And so I will continue to avoid C++ because I'm not a master and will not avoid the many pitfals, and I want to get things done, not become a master of C++.

What a strange language, that so much sage wisdom involves what parts of it you shouldn't use. (Former C++ programmer, a long time ago, before the "don't use these parts" advice became a thing.)

Yes, it shares that 'feature' in common with JavaScript.
Post reply on HN