Live data from Hacker News

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

250bpm.com

141–147 of 147 posts

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

#141
post #12

Earlier quoted context omitted.

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.

Off topic, but: I thought in rust they like to statically link everything. So how does that go with the LGPL license you chose?

I think that the requirement is that anyone who releases a program that was linked with my library must also release it in a form that allows it to be relinked without the library. I'm not sure how that applies to Rust's linkage model.

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

#142
post #83
post #12

Earlier quoted context omitted.

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.

How is it possible to write a no-allocation intrusive linked list without move constructors ? When you move one of the nodes (or sentinel if you use one) it would invalidate the links in other nodes.

The list takes an OwningPointer to the object to be inserted. One of the requirements of this trait (which is unsafe to implement) is "the object cannot be moved while in the `LinkedList`." So Box would work, or a mutable reference would as well (the library implements the trait for these types already). The list itself doesn't do the allocation though.

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

#143
post #66

Earlier quoted context omitted.

"Number of pages in specification" is a rather useless metric to use to compare languages, since there are so many variables. And not just things like point size or margins or what have you, but the contents themselves vary. Some specifications include an EBNF grammar, others may try to describe it via natural-language rules, and others may just say "see the reference implementation". Some specifications include docu…

> "Number of pages in specification" is a rather useless metric to use to compare languages, since there are so many variables. How would you prefer to compare language sizes? Gut feel? Surely that's even worse. I'll certainly admit that - like LOC measurements - it's a metric one can't take too seriously on it's own. On the other hand, it's a useful starting point for discussing said variables. For example, when I w…

  > How would you prefer to compare language sizes? Gut 
  > feel? Surely that's even worse.
Why is it necessary to compare "language sizes" at all? Nobody has ever demonstrated that the "size" of a language (by any definition) has any measurable effect on the quality of the software written in that language. It's as pointless as the classic vim vs. emacs argument.

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

#144
post #143

Earlier quoted context omitted.

> "Number of pages in specification" is a rather useless metric to use to compare languages, since there are so many variables. How would you prefer to compare language sizes? Gut feel? Surely that's even worse. I'll certainly admit that - like LOC measurements - it's a metric one can't take too seriously on it's own. On the other hand, it's a useful starting point for discussing said variables. For example, when I w…

> How would you prefer to compare language sizes? Gut > feel? Surely that's even worse. Why is it necessary to compare "language sizes" at all? Nobody has ever demonstrated that the "size" of a language (by any definition) has any measurable effect on the quality of the software written in that language. It's as pointless as the classic vim vs. emacs argument.

> Why is it necessary to compare "language sizes" at all?

It seems relevant in the context of how difficult it is to master a given language, which spawned this thread of debate. Do you disagree that language size is any sort of barrier?

Again, only one metric, to be taken with a measure of salt. But would you prefer we compare languages based on gut feel? Or is comparing languages unnecessary as well?

> It's as pointless as the classic vim vs. emacs argument.

Understanding the merits of vim vs. emacs informs you which you might prefer. The answer to that argument, over which is "ultimately better" is certainly pointless. You can simply choose whichever works best for you, especially as you can change your mind mostly at will.

But people don't simply have the choice of "choose whichever works best for you" when it comes to programming languages on a team project. Nor are languages as fungible as editors when it comes to changing your mind - switching languages mid-project is a massive time sink, and frequently fatal to the project.

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

#145
post #38

Earlier quoted context omitted.

Is this a sort of informal RFQ? What's your budget?

There's no shortage of people taking a stab at language design and even resources to pull it off. The post was intended to provide a simple route for making (a) a better C++ or (b) a ZeroMQ variant with improved robustness & maintenance. Just inspiration and stuff to think about. If I had a budget, a few companies that can get the job done would already have the contract.

Oh, I think I see — you're generously sharing your language-design expertise by guiding us towards working on things whose potential you can see, potential that a less experienced or talented person might miss?

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

#146
post #145

Earlier quoted context omitted.

There's no shortage of people taking a stab at language design and even resources to pull it off. The post was intended to provide a simple route for making (a) a better C++ or (b) a ZeroMQ variant with improved robustness & maintenance. Just inspiration and stuff to think about. If I had a budget, a few companies that can get the job done would already have the contract.

Oh, I think I see — you're generously sharing your language-design expertise by guiding us towards working on things whose potential you can see, potential that a less experienced or talented person might miss?

Close, but that's an elitist attitude. More like I help things along by sharing lessons learned from thousands of academic papers, industrial case studies, and so on that I've read. Our industry has a problem where it continuously forgets past accomplishments and solutions. An example is the "can an OS be written in a managed language?" question that keeps popping up despite it being done a half-dozen times. Or endless tactics to avoid stack-smashing while MULTICS's reverse stack solved the root problem in early 70's. Can we scale linearly to thousands of nodes with strong consistency? NonStop and some MPP's did that in the 80's while publishing how.

So, it's not that people are stupid or inferior to me. They've just put more of their time in other things (eg work, coding) rather than digging out gems stored behind paywalls or published in obscure places. I've been digging for years along with R&D on much of it. I share that stuff where it might help and it's helped many people/companies in the past. So, I keep doing it.

People are free to ignore any suggestions. About 99.999% do.

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

#147
post #64

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.

A common way to solve that is to have a function argument point to a place where you want the result to end up, and always return FOO_ERROR or FOO_OK. i.e., int foo_new(foo_t **res); int foo_mutate_copy(foo_t *foo, bar_t *bar, foo_t **new_foo); Instead of foo_t *foo_new(); // returns NULL on failure foo_t *foo_mutate_copy(foo_t *foo, bar_t *bar); // returns NULL on failure I also like the Go way, just thought this wa…

>using up your only return value and having to take pointer arguments when you would rather not.

I specifically mention the C way of doing things- but use you demonstrate it above. I was suggesting the Go way is superior.

Post reply on HN