17 ms·

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement or judgment on Rust. At most there's an interesting point on it's value proposition: > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 10 years for adoption, let people should switch languages? DELUSION. This is mostly true. Developers in particular don't generally care about security, so selling Rust as a "secure" language is not going to be enough. I've said this since 1.0. But it's not entirely true for products, which often drive development - Chrome's pairing of performance and security led to tons of marketing wins. Given that tools like "cat" etc are: a) Not generally security sensitive b) Target developers I don't see anyone choosing the "rust cat" over the builtin. This is why people build tools like "bat", that aren't just memory safe copies, but they're memory safe tools that add features and target slightly different cases. Not much else to get from this post, I think.

hvs 6y ago
This is pretty much a judgment of Rust: Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Consider me a skeptic -- I think these compiler ecosystems face a grim bloaty future. I would think that OpenBSD developers/users would care about security, since that's pretty much the value-proposition of OpenBSD.
- staticassertion 6y ago
  > This is pretty much a judgment of Rust: I guess. It's really a judgment of Rust (specifically the compiler toolchain) for this one use case. > I would think that OpenBSD developers/users would care about security, Maybe. Again, I think "cat" and other system tools are really low on the list of priorities for anyone securing a system. Not to say that they don't represent attack surface, by any means, but there are just a lot of things to do before rewriting the utility entirely.
  - numbsafari 6y ago
    “cat” and related tools make perfectly interesting exploit targets on Unix systems that follow the Unix philosophy: https://www.cvedetails.com/cve/CVE-2014-9471/ https://www.cvedetails.com/cve/CVE-2014-9471/
    - staticassertion 6y ago
      There is a big difference between being having vulnerabilities and being valuable attack surface. Again, I am not saying that cat and others do not provide attack surface, or even valuable attack surface, only that step 1 is not "rewrite cat". Generally "cat" is not exposed to the internet, and if you're running a service and you said "I'm concerned about local attackers using cat" it's probably a lot easier to just put the service into some sort of environment (container, sandbox, user, whatever) that doesn't give access to cat.
      - numbsafari 6y ago
        > step 1 is not "rewrite cat" Totally agree on this point. In fact, I think it’s brash for the rust armada to think that the borrow checker alone is going to help replace 20+ years of maintenance on these kinds of tools, which often crufty, and gnarled by the sands and whims of generations that preceded us.
        staticassertion 6y ago
        As a member of the Rust Armada I can tell you that I don't believe that rewriting cat in rust is something I consider a high priority.
    - anthk 6y ago
      That's not BSD cat, that's GNU cat. And I am using AWK and KSH + dcgi in my Gopher server with a chrooted root gopher hole, it works fine.
      - numbsafari 6y ago
- naasking 6y ago
  Bizarre that he thinks a language or compiler is doomed unless it can compile itself on each platform it supports. Microcontrollers and cross-compilation wouldn't exist if that were the case.
  - aidenn0 6y ago
    I think it was more the implication that requiring more than 2GB of RAM to compile itself was an indication of its profligate resource usage.
    - qppo 6y ago
      How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.
      - aidenn0 6y ago
        Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?
        adrianN 6y ago
        No, I don't think so. If LLVM is at fault then the issue is definitely not inherent to Rust the language or Rust the development culture.
        kzrdude 6y ago
        Interesting point. Does anyone know how much memory is needed to compile llvm+clang? GCC?
        anthk 6y ago
        IDK about compiling llvm/clang, but using clang/llvm needs far less memory than gcc. I've used clang in machines with less than 256mb of RAM.
- pnako 6y ago
  They do care about security. They just don't care about Rust.
  - staticassertion 6y ago
    They can not care about more than one thing.
fluffything 6y ago
> Developers in particular don't generally care about security, Bad developers don't, but many developers do. The Rust project itself has hundreds of contributors, to the point that it feels that it has more contributors than LLVM itself (I work on both, and this is an unbacked feeling I get from the velocity of the contributions). Point being, if developers wouldn't care about Rust, they wouldn't be developing it.
- staticassertion 6y ago
  Maybe I shouldn't have said that, because it's contentious, but I do believe it to be true. I believe Rust's success has less to do with memory safety, which I think most developers (anyone coming from a GC'd language) consider table stakes, and much more to do with great documentation and incredibly powerful primitives and ecosystem such as the type system, cargo, crates.io, etc.
  - fluffything 6y ago
    A GC only protects you from memory errors, not threading errors. In general, Rust allows you to write software that doesn't break silently. That's a quite good value proposition for large scale software, where other languages often require programers to be super careful with refactorings, while in Rust you can really refactor all the things. The reason people are afraid to do large refactorings in say C++ is often "security-related": fear of introducing segfaults, memory errors, undefined behavior, threading errors, etc. but one can also see these fears as "productivity-related" (hours and hours of debugging), or through many other lenses (shipping bugs to users, having a segfault in the middle of a demo that costs you a client, introducing a segfault one day before the release of your game, etc.). In general, every programmer wants to have a certain degree of security that their software "works" for some definition of "works". For some this security might be actual network security, but for others it might mean that they don't want their data-science app that has been running for a week burning thousands of dollars to crash due to a segfault while writing the results.
    - pjmlp 6y ago
throwaway894345 6y ago
Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact locations on the filesystem that the build tooling is willing to look. Autotools and CMake are absolutely terrible; they make Python’s build ecosystem look sane and well-designed. So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software. Specifically, hasten the day where my entire application dependency tree doesn’t bottom out in some Autotools, CMake, shell script, project.
- toast0 6y ago
  > Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. This is an area where the BSDs are pretty good. There may not be a dependency system here exactly, but because XBSD base builds XBSD base, everything you need is in one checkout. Generally with just (BSD) Make driving the build. Programs outside of base are genrerally built with Portfiles which specify dependencies such that (BSD) Make can satisfy them. But somebody has to write the Portfile, and it's often not the authors of the program.
- sjakobi 6y ago
  Regarding build tools for C, you might find this one interesting: https://github.com/vmchale/cpkg https://github.com/vmchale/cpkg
  - throwaway894345 6y ago
    Yeah, there are lots of good build systems for C (didn’t know about this one; will have a look; thanks for sharing), but the problem is that they have tiny adoption, especially among “core” ecosystem packages, like coreutils and friends. The problem isn’t technical, it’s political and cultural. This ecosystem is hostile toward its users for no discernible reason. If anyone knows of a distribution that aims to use only software with sane build systems, let me know, I would be very curious.
bluejekyll 6y ago
I like bat more than cat, not because it’s memory safe, but because it’s benefiting from the entire Rust ecosystem and provides features I enjoy that cat does not have. It’s not always security, but that’s always a plus (though I have no idea if bat is any more secure than cat). I can make the same statement about exa and many of the other tools that are getting better in the Rust suite of CLI tools.
- jen20 6y ago
  Indeed, I came here to say that I’ve replaced many such standard tools with more functional equivalents which happen to be written using Rust - bat, git-delta etc.
black_puppydog 6y ago
Anecdata to the rescue: since installing ripgrep, my use of grep has plummeted. If I ever use it, it's because it comes as part for a copy/paste command I'm running.
benibela 6y ago
> This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". If people wanted memory safety so much, they could have done that years ago with Java
hedora 6y ago
> Developers in particular don't generally care about security, so selling Rust as a "secure" language is not going to be enough. You do realize that OpenBSD is, by far, the most secure general purpose operating system specifically due to decades of thankless work by people like Theo de Raadt, right? I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security.
- staticassertion 6y ago
  > You do realize that OpenBSD is, by far, the most secure general purpose operating system specifically due to decades of thankless work by people like Theo de Raadt, right? Yes, I think it is fair to say that I am very familiar with all of this information. I work in information security, and was quite into Linux kernel security for a while. I disagree with your assertion about it being the most secure general purpose OS but I'm not gonna go there :) > I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security. Cool, that was not my conclusion either. I'm saying that Rust's value proposition in general includes memory safety and I think that it's not compelling for most developers, especially with regards to rewrites of low-value attack surface.
  - cosmojg 6y ago
    > I disagree with your assertion about it being the most secure general purpose OS but I'm not gonna go there :) Could you please go there? I'm very curious what the contenders for "most secure general purpose OS" might be.
    - staticassertion 6y ago
      I think geofft's points go a long way. I think having this conversation would require a lot though - what is "Secure" what is "general purpose". Is OpenBSD even general purpose? Is the base install general purpose? What makes an OS secure? I think maybe as a "with 0 configuration to the OS/ services" OpenBSD could be a top contender. With "I have practical security challenges to solve and I'm willing to change things in this system" I might choose Linux. If I'm handing a laptop out to an employee or friend, maybe a Chromebook, or even Windows! It's a pretty nuanced discussion that I couldn't do justice to without really caring and feeling that everyone involved in the conversation is equally invested/ coming in with the right attitude, which is impossible on an internet forum.
danaliv 6y ago
In a thread about OpenBSD, > Developers in particular don't generally care about security Thanks, now I have to clean a mouthful of coffee off my screen!
- staticassertion 6y ago
  Is the joke that Theo said virtually the exact same thing in the linked thread? Again, quoting Theo directly... > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 10 years for adoption, let people should switch languages? DELUSION. Anyways, I think you've clearly misunderstood my point.
stcredzero 6y ago
However there is a rampant fiction that if you supply a new safer method everyone will use it. A fiction indeed. This is how developers actually behave. If you build a better mousetrap, lots of developers will all too quickly give you n reasons why it's terrible, and why you won't be able to pry their (punch cards/assembler/compiler/favorite-language/favorite-tool) out of their cold, dead hands. This has been true, literally since the modern era of computer programming began in the middle of the last century, and it shows no signs of abating.
dang 6y ago
Yes, we've changed the title from "Theo de Raadt on Rust", which broke the site guidelines: "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- zozbot234 6y ago
  (2017)
  - dang 6y ago
    Oh good grief. I don't know how we missed that. Added now, thanks! HN has enough sensational Rust discussions with fresh articles and didn't need to supplement those with a 3-year-old one. Oh well, win some lose some.
rurban 6y ago
A lot is missing also. First he doesn't know about ripgrep, which is far better than GNU or BSD grep. Second,none of the known grep's can find unicode strings. Redhat carried along the uni patches for a while, but when people complained about performance on the new utf8 locales, they dropped it. coreutils is still missing unicode support, so we don't find equivalent strings with different bytes. No normalization, no fold casing. Rust based coreutils could solve that, because they have the proper libs which are better than in C land and could survive the perf critics. Third, rust is not secure. Just more secure than C. Memory safety, thread safety and type safety are lies. People buy it, but Theo should know.
- anthk 6y ago
  - Theo doesn't give a shit on ripgrep, but grep(1) complying with standards and working under OpenBSD scripts. - I am using grep(1) on unicode stuff in Spanish on XTerm just fine, even in ed(1). This is not a GNU craputils base, but the OpenBSD one. Heck, I type Spanish only characters with ed(1) in order to write my phlog. I can use nvi(1) from ports, but ed(1), fold(1) and ispell(1) are more than enough and I can forget about switching modes. - That's a great example of Cargo Cult. - On Unix and descendants, plan9 gave us UTF8, and fore sure it's grep supports more UTF8 stuff than your non-existant Rust based OS.
- burntsushi 6y ago
  > First he doesn't know about ripgrep ripgrep isn't POSIX compliant. Never was and never will be. So I don't think it's really applicable here. ripgrep is maybe an existence proof that a competing tool can be written, but it is certainly not a suitable POSIX compliant grep replacement. Building a fully POSIX compliant grep tool with good performance like GNU grep is pretty difficult. It could be done. It would probably take me a couple months (and only by leveraging my existing work). I just don't have any incentive to do it, personally. > Second,none of the known grep's can find unicode strings. That's definitely not true. GNU grep can do this just fine: $ echo 'Δ' | LC_ALL=en_US.UTF-8 grep '\w' Δ $ echo 'Δ' | LC_ALL=en_US.UTF-8 grep 'δ' -i Δ GNU grep does pay more of a performance penalty for Unicode support than ripgrep does. It's easy to see this with a somewhat pathological case by comparing `rg '\w{42}'` with `LC_ALL=en_US.UTF-8 grep -E '\w{42}'`. (Not all cases are pathological, but ripgrep and GNU grep are both very good about literal optimizations, so it's easiest to demonstrate with a pathological case.) I'm not sure if one can attribute this to better library support in the Rust ecosystem though. It's really about how the regex machinery itself is built.

hvs 6y ago

This is pretty much a judgment of Rust: Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Consider me a skeptic -- I think these compiler ecosystems face a grim bloaty future. I would think that OpenBSD developers/users would care about security, since that's pretty much the value-proposition of OpenBSD.

staticassertion 6y ago
> This is pretty much a judgment of Rust: I guess. It's really a judgment of Rust (specifically the compiler toolchain) for this one use case. > I would think that OpenBSD developers/users would care about security, Maybe. Again, I think "cat" and other system tools are really low on the list of priorities for anyone securing a system. Not to say that they don't represent attack surface, by any means, but there are just a lot of things to do before rewriting the utility entirely.
- numbsafari 6y ago
  “cat” and related tools make perfectly interesting exploit targets on Unix systems that follow the Unix philosophy: https://www.cvedetails.com/cve/CVE-2014-9471/ https://www.cvedetails.com/cve/CVE-2014-9471/
  - staticassertion 6y ago
    There is a big difference between being having vulnerabilities and being valuable attack surface. Again, I am not saying that cat and others do not provide attack surface, or even valuable attack surface, only that step 1 is not "rewrite cat". Generally "cat" is not exposed to the internet, and if you're running a service and you said "I'm concerned about local attackers using cat" it's probably a lot easier to just put the service into some sort of environment (container, sandbox, user, whatever) that doesn't give access to cat.
    - numbsafari 6y ago
      > step 1 is not "rewrite cat" Totally agree on this point. In fact, I think it’s brash for the rust armada to think that the borrow checker alone is going to help replace 20+ years of maintenance on these kinds of tools, which often crufty, and gnarled by the sands and whims of generations that preceded us.
      - staticassertion 6y ago
        As a member of the Rust Armada I can tell you that I don't believe that rewriting cat in rust is something I consider a high priority.
  - anthk 6y ago
    That's not BSD cat, that's GNU cat. And I am using AWK and KSH + dcgi in my Gopher server with a chrooted root gopher hole, it works fine.
    - numbsafari 6y ago
naasking 6y ago
Bizarre that he thinks a language or compiler is doomed unless it can compile itself on each platform it supports. Microcontrollers and cross-compilation wouldn't exist if that were the case.
- aidenn0 6y ago
  I think it was more the implication that requiring more than 2GB of RAM to compile itself was an indication of its profligate resource usage.
  - qppo 6y ago
    How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.
    - aidenn0 6y ago
      Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?
      - adrianN 6y ago
        No, I don't think so. If LLVM is at fault then the issue is definitely not inherent to Rust the language or Rust the development culture.
        kzrdude 6y ago
        Interesting point. Does anyone know how much memory is needed to compile llvm+clang? GCC?
        anthk 6y ago
        IDK about compiling llvm/clang, but using clang/llvm needs far less memory than gcc. I've used clang in machines with less than 256mb of RAM.
pnako 6y ago
They do care about security. They just don't care about Rust.
- staticassertion 6y ago
  They can not care about more than one thing.

fluffything 6y ago

> Developers in particular don't generally care about security, Bad developers don't, but many developers do. The Rust project itself has hundreds of contributors, to the point that it feels that it has more contributors than LLVM itself (I work on both, and this is an unbacked feeling I get from the velocity of the contributions). Point being, if developers wouldn't care about Rust, they wouldn't be developing it.

staticassertion 6y ago
Maybe I shouldn't have said that, because it's contentious, but I do believe it to be true. I believe Rust's success has less to do with memory safety, which I think most developers (anyone coming from a GC'd language) consider table stakes, and much more to do with great documentation and incredibly powerful primitives and ecosystem such as the type system, cargo, crates.io, etc.
- fluffything 6y ago
  A GC only protects you from memory errors, not threading errors. In general, Rust allows you to write software that doesn't break silently. That's a quite good value proposition for large scale software, where other languages often require programers to be super careful with refactorings, while in Rust you can really refactor all the things. The reason people are afraid to do large refactorings in say C++ is often "security-related": fear of introducing segfaults, memory errors, undefined behavior, threading errors, etc. but one can also see these fears as "productivity-related" (hours and hours of debugging), or through many other lenses (shipping bugs to users, having a segfault in the middle of a demo that costs you a client, introducing a segfault one day before the release of your game, etc.). In general, every programmer wants to have a certain degree of security that their software "works" for some definition of "works". For some this security might be actual network security, but for others it might mean that they don't want their data-science app that has been running for a week burning thousands of dollars to crash due to a segfault while writing the results.
  - pjmlp 6y ago

throwaway894345 6y ago

Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact locations on the filesystem that the build tooling is willing to look. Autotools and CMake are absolutely terrible; they make Python’s build ecosystem look sane and well-designed. So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software. Specifically, hasten the day where my entire application dependency tree doesn’t bottom out in some Autotools, CMake, shell script, project.

toast0 6y ago
> Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. This is an area where the BSDs are pretty good. There may not be a dependency system here exactly, but because XBSD base builds XBSD base, everything you need is in one checkout. Generally with just (BSD) Make driving the build. Programs outside of base are genrerally built with Portfiles which specify dependencies such that (BSD) Make can satisfy them. But somebody has to write the Portfile, and it's often not the authors of the program.
sjakobi 6y ago
Regarding build tools for C, you might find this one interesting: https://github.com/vmchale/cpkg https://github.com/vmchale/cpkg
- throwaway894345 6y ago
  Yeah, there are lots of good build systems for C (didn’t know about this one; will have a look; thanks for sharing), but the problem is that they have tiny adoption, especially among “core” ecosystem packages, like coreutils and friends. The problem isn’t technical, it’s political and cultural. This ecosystem is hostile toward its users for no discernible reason. If anyone knows of a distribution that aims to use only software with sane build systems, let me know, I would be very curious.

bluejekyll 6y ago

I like bat more than cat, not because it’s memory safe, but because it’s benefiting from the entire Rust ecosystem and provides features I enjoy that cat does not have. It’s not always security, but that’s always a plus (though I have no idea if bat is any more secure than cat). I can make the same statement about exa and many of the other tools that are getting better in the Rust suite of CLI tools.

jen20 6y ago
Indeed, I came here to say that I’ve replaced many such standard tools with more functional equivalents which happen to be written using Rust - bat, git-delta etc.

black_puppydog 6y ago

Anecdata to the rescue: since installing ripgrep, my use of grep has plummeted. If I ever use it, it's because it comes as part for a copy/paste command I'm running.

benibela 6y ago

> This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". If people wanted memory safety so much, they could have done that years ago with Java

hedora 6y ago

> Developers in particular don't generally care about security, so selling Rust as a "secure" language is not going to be enough. You do realize that OpenBSD is, by far, the most secure general purpose operating system specifically due to decades of thankless work by people like Theo de Raadt, right? I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security.

staticassertion 6y ago
> You do realize that OpenBSD is, by far, the most secure general purpose operating system specifically due to decades of thankless work by people like Theo de Raadt, right? Yes, I think it is fair to say that I am very familiar with all of this information. I work in information security, and was quite into Linux kernel security for a while. I disagree with your assertion about it being the most secure general purpose OS but I'm not gonna go there :) > I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security. Cool, that was not my conclusion either. I'm saying that Rust's value proposition in general includes memory safety and I think that it's not compelling for most developers, especially with regards to rewrites of low-value attack surface.
- cosmojg 6y ago
  > I disagree with your assertion about it being the most secure general purpose OS but I'm not gonna go there :) Could you please go there? I'm very curious what the contenders for "most secure general purpose OS" might be.
  - staticassertion 6y ago
    I think geofft's points go a long way. I think having this conversation would require a lot though - what is "Secure" what is "general purpose". Is OpenBSD even general purpose? Is the base install general purpose? What makes an OS secure? I think maybe as a "with 0 configuration to the OS/ services" OpenBSD could be a top contender. With "I have practical security challenges to solve and I'm willing to change things in this system" I might choose Linux. If I'm handing a laptop out to an employee or friend, maybe a Chromebook, or even Windows! It's a pretty nuanced discussion that I couldn't do justice to without really caring and feeling that everyone involved in the conversation is equally invested/ coming in with the right attitude, which is impossible on an internet forum.

danaliv 6y ago

In a thread about OpenBSD, > Developers in particular don't generally care about security Thanks, now I have to clean a mouthful of coffee off my screen!

staticassertion 6y ago
Is the joke that Theo said virtually the exact same thing in the linked thread? Again, quoting Theo directly... > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 10 years for adoption, let people should switch languages? DELUSION. Anyways, I think you've clearly misunderstood my point.

stcredzero 6y ago

However there is a rampant fiction that if you supply a new safer method everyone will use it. A fiction indeed. This is how developers actually behave. If you build a better mousetrap, lots of developers will all too quickly give you n reasons why it's terrible, and why you won't be able to pry their (punch cards/assembler/compiler/favorite-language/favorite-tool) out of their cold, dead hands. This has been true, literally since the modern era of computer programming began in the middle of the last century, and it shows no signs of abating.

dang 6y ago

Yes, we've changed the title from "Theo de Raadt on Rust", which broke the site guidelines: "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

zozbot234 6y ago
(2017)
- dang 6y ago
  Oh good grief. I don't know how we missed that. Added now, thanks! HN has enough sensational Rust discussions with fresh articles and didn't need to supplement those with a 3-year-old one. Oh well, win some lose some.

rurban 6y ago

A lot is missing also. First he doesn't know about ripgrep, which is far better than GNU or BSD grep. Second,none of the known grep's can find unicode strings. Redhat carried along the uni patches for a while, but when people complained about performance on the new utf8 locales, they dropped it. coreutils is still missing unicode support, so we don't find equivalent strings with different bytes. No normalization, no fold casing. Rust based coreutils could solve that, because they have the proper libs which are better than in C land and could survive the perf critics. Third, rust is not secure. Just more secure than C. Memory safety, thread safety and type safety are lies. People buy it, but Theo should know.

anthk 6y ago
- Theo doesn't give a shit on ripgrep, but grep(1) complying with standards and working under OpenBSD scripts. - I am using grep(1) on unicode stuff in Spanish on XTerm just fine, even in ed(1). This is not a GNU craputils base, but the OpenBSD one. Heck, I type Spanish only characters with ed(1) in order to write my phlog. I can use nvi(1) from ports, but ed(1), fold(1) and ispell(1) are more than enough and I can forget about switching modes. - That's a great example of Cargo Cult. - On Unix and descendants, plan9 gave us UTF8, and fore sure it's grep supports more UTF8 stuff than your non-existant Rust based OS.
burntsushi 6y ago
> First he doesn't know about ripgrep ripgrep isn't POSIX compliant. Never was and never will be. So I don't think it's really applicable here. ripgrep is maybe an existence proof that a competing tool can be written, but it is certainly not a suitable POSIX compliant grep replacement. Building a fully POSIX compliant grep tool with good performance like GNU grep is pretty difficult. It could be done. It would probably take me a couple months (and only by leveraging my existing work). I just don't have any incentive to do it, personally. > Second,none of the known grep's can find unicode strings. That's definitely not true. GNU grep can do this just fine: $ echo 'Δ' | LC_ALL=en_US.UTF-8 grep '\w' Δ $ echo 'Δ' | LC_ALL=en_US.UTF-8 grep 'δ' -i Δ GNU grep does pay more of a performance penalty for Unicode support than ripgrep does. It's easy to see this with a somewhat pathological case by comparing `rg '\w{42}'` with `LC_ALL=en_US.UTF-8 grep -E '\w{42}'`. (Not all cases are pathological, but ripgrep and GNU grep are both very good about literal optimizations, so it's easiest to demonstrate with a pathological case.) I'm not sure if one can attribute this to better library support in the Rust ecosystem though. It's really about how the regex machinery itself is built.