4 ms·

Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the

Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the areas where it is king. I am looking at a crap ton of programs with an UI. Your IDE, your text editor, your spreadsheet program, your graphics editor, etc. Most of the modern programs just give up and ship as a full blown bloated memory eating web browser. There is a gap between the nineties and now, and it is still void. If you have to constrain it to CLI apps the average developer here on HN needs to write, I don´t see a reason to use such a complex beast as Rust. If you mean operating systems, I can see a spot for Rust. Also database systems or a web server implementation. But that is fairly niche. For userland cli-apps I am not sure if the added complexity pays of in terms of sufficient performance gains in practice. If you want to write a new implementation of grep, sure. But how niche is that? So in those cases where you need both type strictness (which I agree should be the default requirement) and cannot have an automatic garbage collector, I can see the value of Rust. But for what audience is an automatic GC really a problem? Personally I would use Haskell, Java, F# for CLI-apps, but I know there are tons of other options there.

xxs 4y ago
grep inner loops are coded straight in Assembly. So Rust would be a poor fit.
- steveklabnik 4y ago
  Yet ripgrep is extremely fast, often faster than grep. Practice beats theory. (Rust can also do in-line assembly…)
- burntsushi 4y ago
  Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?
  - metaltyphoon 4y ago
    If I would have to guess it would be codecs.
    - burntsushi 4y ago
      What do codecs have to do with grep?
      - int_19h 4y ago
        grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv). However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.
        burntsushi 4y ago
        Those are locales. I've never heard them referred to as "codecs." In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)
        int_19h 4y ago
        "en_US.UTF-8" is a locale. The "UTF-8" part is the encoding of that locale. Codec would be whatever piece of code parses the encoding.
        xxs 4y ago
        >in the kernel that gets executed due to some syscall from grep That won't be considered 'inner loop'
  - xxs 4y ago
    ugrep has full SSE/AVX support https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8ce0af9cfca159d1cff4/lib/matcher.cpp#L878 https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8c...
    - burntsushi 4y ago
      So does ripgrep... Which is written in Rust. So how exactly is Rust a poor fit? And that isn't Assembly. So I guess what you said earlier, "grep inner loops are coded straight in Assembly," was a misrepresentation. And that "Rust was a poor fit" is just empirically wrong.
int_19h 4y ago
For CLI apps, performance may be important, and Rust offers a performance profile similar to C++. This is exactly the niche where relying on an automatic GC may be undesirable. But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC. It kinda makes sense if you only focus on management of memory as a resource, but it ignores the whole race condition angle (which very much still exists in GC'd languages like Go or Java).
- exceptione 4y ago
  «But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC.» Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice. My point is: there are tons of GUI applications written in C++. And to this day there are still new projects that pick C++ because it needs a GUI. I consider that a bad thing for Rust. Thinking Rust should be at the CLI-apps competition is just a way to avoid C++. It is the wrong contest, and I am not sure if Rust is even able to win that contest because what Rust has to offer (no GC) isn´t of interest for most CLI apps. I think cli apps like kubectl would not be hurt by being GC'ed. I think that the Rust leadership should identify that GUI is the first city they need to liberate from C++ if they ever dream to replace C++. I just learned some original work has started by various projects, so I keep my fingers crossed.
  - int_19h 4y ago
    The question, rather, is why one would want to use C++ rather than something higher-level (e.g. C#, Java, Swift) for a GUI app in 2022. We're long past the point where performance benefits were worth writing the whole thing that way. Most apps can get away without anything C-like at all, and for the few that need that perf boost, it's easier to implement the corresponding part as a C++ library called from higher-level GUI code. In such an architecture, Rust can transparently replace C++.
    - 4y ago

xxs 4y ago

grep inner loops are coded straight in Assembly. So Rust would be a poor fit.

steveklabnik 4y ago
Yet ripgrep is extremely fast, often faster than grep. Practice beats theory. (Rust can also do in-line assembly…)
burntsushi 4y ago
Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?
- metaltyphoon 4y ago
  If I would have to guess it would be codecs.
  - burntsushi 4y ago
    What do codecs have to do with grep?
    - int_19h 4y ago
      grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv). However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.
      - burntsushi 4y ago
        Those are locales. I've never heard them referred to as "codecs." In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)
        int_19h 4y ago
        "en_US.UTF-8" is a locale. The "UTF-8" part is the encoding of that locale. Codec would be whatever piece of code parses the encoding.
      - xxs 4y ago
        >in the kernel that gets executed due to some syscall from grep That won't be considered 'inner loop'
- xxs 4y ago
  ugrep has full SSE/AVX support https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8ce0af9cfca159d1cff4/lib/matcher.cpp#L878 https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8c...
  - burntsushi 4y ago
    So does ripgrep... Which is written in Rust. So how exactly is Rust a poor fit? And that isn't Assembly. So I guess what you said earlier, "grep inner loops are coded straight in Assembly," was a misrepresentation. And that "Rust was a poor fit" is just empirically wrong.

int_19h 4y ago

For CLI apps, performance may be important, and Rust offers a performance profile similar to C++. This is exactly the niche where relying on an automatic GC may be undesirable. But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC. It kinda makes sense if you only focus on management of memory as a resource, but it ignores the whole race condition angle (which very much still exists in GC'd languages like Go or Java).

exceptione 4y ago
«But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC.» Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice. My point is: there are tons of GUI applications written in C++. And to this day there are still new projects that pick C++ because it needs a GUI. I consider that a bad thing for Rust. Thinking Rust should be at the CLI-apps competition is just a way to avoid C++. It is the wrong contest, and I am not sure if Rust is even able to win that contest because what Rust has to offer (no GC) isn´t of interest for most CLI apps. I think cli apps like kubectl would not be hurt by being GC'ed. I think that the Rust leadership should identify that GUI is the first city they need to liberate from C++ if they ever dream to replace C++. I just learned some original work has started by various projects, so I keep my fingers crossed.
- int_19h 4y ago
  The question, rather, is why one would want to use C++ rather than something higher-level (e.g. C#, Java, Swift) for a GUI app in 2022. We're long past the point where performance benefits were worth writing the whole thing that way. Most apps can get away without anything C-like at all, and for the few that need that perf boost, it's easier to implement the corresponding part as a C++ library called from higher-level GUI code. In such an architecture, Rust can transparently replace C++.
  - 4y ago