Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

250bpm.com

Post reply on HN
Print view View original

21–30 of 147 posts

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

#21

Post by tokenizerrr »

dcu wrote: post #15
rkwasny wrote: 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.

My problem with Go (and I love the language a lot) is that a lot of my error handling is "stop execution in the function and bubble the error up", which results in my code being littered with if err != nil { return err }, which is a bit annoying.

If I'm doing something wrong here I'd love to know it.

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

#22

Post by neverartful »

nickpsecurity wrote: post #7

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…

Objective-C: "You messaged?"

I believe that Objective C is a pretty good (yes, it's getting old) combination of C compatibility with object oriented features as well. The 2 big downsides IMO are: (1) essentially restricted to Apple ecosystem and (2) the syntax keeps a lot of developers away.

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

#23

Post by bajsejohannes »

gridspy wrote: post #20
a3n wrote: post #16

Earlier quoted context omitted.

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.

No, actually, it doesn't. C++ is a huge language, javascript is a relativly small one. I know it's funny to compare the size of "Javascript the good parts" with "Javascript the definitive guide", but that's can be attributed to writing style more than percentage of language covered.

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

#24

Post by cjslep »

cjensen wrote: post #13
voidlogic wrote: post #11

Earlier quoted context omitted.

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

While it works, it would be better if multiple return types were supported natively by the C++ language precisely because of this:

    #ifdef _WIN32
    #    ifdef EXPORTING
    #        define DECL __declspec(dllexport)
    #        define STORAGE
    #    else
    #        define DECL __declspec(dllimport)
    #        define STORAGE extern
    #    endif
    #else
    #    define DECL
    #    define STORAGE
    #endif

    // For every return tuple type actually used:
    STORAGE template class DECL std::tuple;
    STORAGE template class DECL std::tuple;
    STORAGE template class DECL std::tuple;
    // etc.
Even without the above, exposing STL across shared objects leads to the games of "which side of the shared object did this get created" and "which STL did this shared object link against". Losing these games leads to sizeable butt pain.

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

#25

Post by gue5t »

marktangotango wrote: post #18
voidlogic wrote: post #9

Earlier quoted context omitted.

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

Vala is not a C# subset (though it does significantly resemble C#) and really isn't intended or suitable for writing high-performance code or reusable low-level libraries like C or C++ are; it's a way to write GObject-style C without as much boilerplate as it takes in C.

For that niche it's quite nice, and helps avoid refcounting errors which can be very subtle in C, but Vala is still a fairly leaky abstraction over the C to which it compiles.

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

#26

Post by dragontamer »

rando3826 wrote: post #14
jsolson wrote: 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++.

Good luck finding a language out there that doesn't have pitfalls.

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

#27

Post by vardump »

tokenizerrr wrote: post #21
dcu wrote: post #15

Earlier quoted context omitted.

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.

My problem with Go (and I love the language a lot) is that a lot of my error handling is "stop execution in the function and bubble the error up", which results in my code being littered with if err != nil { return err }, which is a bit annoying. If I'm doing something wrong here I'd love to know it.

You're not doing anything wrong. And I think it's better that way, to have the error possibilities visible and very understandable. All the context you need to see the error handling is in front of you, not hidden in 25 different files. That's a blessing.

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

#28

Post by nickpsecurity »

voidlogic wrote: post #9
nickpsecurity wrote: post #7

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.

Currently, Go makes some decisions that hurt it for high performance systems, bare metal, and so on. Rust barely survived some beginner OS projects without its bloat and performance problems showing up. Once comparison I read showed Rust's compiler caught many bugs that slipped through Go's due to Rust design choices. I'm pulling for Rust in particular because its team made clever, design choices for their safety-vs-performance&control tradeoffs. Yet, right now, both are inferior to C, C++, Ada, the old Modulas, and even Fortran for bare metal applications.

So, it's not a dream so much as me wanting to see an excellent middleware implemented in a language proven for decades to do what the two you referenced hope to do someday. Using proven methods, even if ugly or unpopular, is just what engineers do when solving new problems. I'd happily use the same thing built in Rust (not Go as it's less safe) if they can get it more compact and fast. Meanwhile, I have to use C++ and C implementations because that's what's available.

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

#29

Post by QuercusMax »

neverartful wrote: post #22
nickpsecurity wrote: post #7

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…

Objective-C: "You messaged?" I believe that Objective C is a pretty good (yes, it's getting old) combination of C compatibility with object oriented features as well. The 2 big downsides IMO are: (1) essentially restricted to Apple ecosystem and (2) the syntax keeps a lot of developers away.

I agree strongly; I never really mastered C++, but I've done lots of Java development and enough C developments in anger to consider myself at least a journeyman C developer. (I know enough C++ to be dangerous.)

The message-passing syntax is such a funny thing to me; it looks weird, but it takes about 1 minute to grok if you try, and then the rest is very simple. It's really dynamic and lets you do some very powerful things that you wouldn't expect to be able to do in a C-derived language (NSProxy, respondsToSelector:, etc.).

I find it very natural when doing ObjC development to write all my high-level code is very "objecty" style, and then call into pure C methods when I'm doing something tricky/low-level/fiddly.

On the downside, though, mostly due to it being old and not very well adopted, ObjC never got a proper generics system, which is really annoying if you're used to Java or C++.

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

#30

Post by nickpsecurity »

neverartful wrote: post #22
nickpsecurity wrote: post #7

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…

Objective-C: "You messaged?" I believe that Objective C is a pretty good (yes, it's getting old) combination of C compatibility with object oriented features as well. The 2 big downsides IMO are: (1) essentially restricted to Apple ecosystem and (2) the syntax keeps a lot of developers away.

My quick perusal of online links show that Objective-C is slower than C++, maybe due to its dynamic typing. It has the C compatibility and basic OOP. Yet, my idea was a language like this which is faster than C++. Maybe a statically typed version of Objective-C would do?
Post reply on HN