Comment by zozbot234

5 years ago

Is this really higher performance than the existing protobuf support in Rust+serde? That uses macro programming to generate code at compile time based on a high-level description of your data format, so it can be quite fast and will certainly be a lot safer than cowboy-coding raw C.

Every single time there is a link about C/C++, I do a quick "Ctrl+F Rust", and every single time there is some rant about "but Rust is safer than C".

Every. Single. Time.

This article is about a new Clang extension:

> An exciting feature just landed in the main branch of the Clang compiler. Using the [[clang::musttail]] or __attribute__((musttail)) statement attributes, you can now get guaranteed tail calls in C, C++, and Objective-C.

(literally the first line of the article)

What does Rust have to do with this? Nothing.

Does the author suggest that you should only use C for high performance? No.

  • > Every single time there is a link about C/C++, I do a quick "Ctrl+F Rust", and every single time there is some rant about "but Rust is safer than C".

    If you had the same reflex with other languages when reading other HN comment thread you'll realize that everytime there's a thread about language A there's a ton of comments about language B or C. Rust threads are full of people talking about C++ or C, why is it supposed to be more OK? Go threads are full of comment about Java, Python threads are full of Go or Julia (depending on what kind of Python this is about). This isn't specific to Rust in any ways.

    Yes, the GP isn't the most useful comment ever, Rust is hype and there are overly enthusiastic people, but there are also people who seem to be overly defensive about it (doing a text search to count Rust occurrences, every time, really?) and I'm not sure the latter is less childish than the former.

    • > If you had the same reflex with other languages

      I do, always, just out of curiosity because seeing peoples view on different languages is always insightful.

      > This isn't specific to Rust in any ways.

      From what I've seen, Rust comments are the most condescending.

      > I'm not sure the latter is less childish than the former.

      It is childish to look for specific information (in this specific case: how C and Rust are compared by others) in threads that grow to hundreds of messages?

      FYI, I've also looked for C++ and Go comments in this thread, and none of them were a condescending comment like "C is bad, you should use Rust, C is evil and should not be sent to production".

      1 reply →

  • > This article is about a new Clang extension:

    > An exciting feature just landed in the main branch of the Clang compiler. Using the [[clang::musttail]] or __attribute__((musttail)) statement attributes, you can now get guaranteed tail calls in C, C++, and Objective-C.

    > What does Rust have to do with this? Nothing.

    Rust has a planned keyword for this exact feature, namely 'become'. So the author would be able to use it in Rust just as well, as soon as support for it lands in an upstream LLVM release.

    Regardless, writing raw C as the article suggests in order to parse a quasi-standard high-level format is cowboy coding. It's a nice hack to be sure, but it's not the kind of code that should be anywhere close to a real production workload. Instead, this feature should be implemented as part of some safe parser generator. Not necessarily written in Rust but something that's at least as safe.

    • > Rust has a planned keyword for this exact feature, namely 'become'. So the author would be able to use it in Rust just as well, as soon as support for it lands in an upstream LLVM release.

      The author is demonstrating a new Clang feature. Then, again, what is the point of mentioning Rust?

      > writing raw C as the article suggests in order to parse a quasi-standard high-level format is cowboy coding.

      So what? Cowboy coding lets you appreciate even more languages where you don't need to do it, AND gives you a better understanding of how they might work.

      > it's not the kind of code that should be anywhere close to a real production workload.

      Again, not a single time in the article the author suggests that.

    • > Instead, this feature should be implemented as part of some safe parser generator

      Which safe parser generator would you recommend for writing a protobuf parser (preferably one that yields at least 25% of the throughput claimed by the OP)?

      Full disclosure: I believe there is no such thing, and if what you're asking the OP is to write one, it would likely benefit greatly from generating code that leverages tail recursion. Yeehaw!