It doesn't. Use C#, Java, or even python. If you're low level and dealing with low level code and constructs, you're better off using C, or C++ just for the language features like templates.
Rust is genuinely only useful for the niche application of a desktop application, that doesn't reach low level, but you need a bit more fine grain controls than C# or another higher level language will allow. For example, a web browser is like the ideal usecase for Rust, and it makes sense, since that's really where it's got most of it's teeth with Mozilla.
I personally don't see why you would do something like Grep, in Rust, when C#, Python, Go, exist. But I do see like Unreal Engine or again, Firefox/webbrowser in Rust being nice.
People have written greps in Go and Python (and Perl), and they aren't even close in all around perf to GNU grep (written in C) or ripgrep (which I wrote in Rust).
Maybe you don't know what you're talking about, despite coming across as certain of yourself.
Powershell actually ships one! I think you have a good point. I was going to build my own as C# ships alot of configuration options that can DRASTICALLY improve speed, which arn't on by default. But, we can test Redmonds version and get at least a decent idea of if it's suitable. I'll run some tests on that and get back to you in an hour or so. I'll use the same tests you have on https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...
My testing will be on my Dev VM, in a WSL container on ubuntu 22.04, targeting a built linux kernel. With powershell from the Microsoft blobs they ship for linux. And Ripgrep from just Apt Install Ripgrep. With 5 warmup cycles for each.
Please be sure to read my blog post that I linked very carefully. Benchmarking greps is rather difficult and quite subtle.
Are you talking about findstr? If so, I'm not sure that's available on Linux. So it doesn't seem like a viable grep to me. If the program you want to be a grep only runs on Windows, then that isn't really viable.
Also, Windows file system operations tend to be quite a bit slower than Linux.
Alright, so initial testing result. I'm not going to even bother putting into excel, RipGrep blew the hell out of Powershells built in stuff. Like, we're talking exponentially quicker, so well done. (3 minutes for Pwsh vs 2 seconds Ripgrep)
But I don't think it's the fault of C# and I think it's the fault of some poor coding on redmonds side, and very good coding on your side. And since I have to make up 12 hours tomorrow at work, but have zero tickets. I'll probably go in and write a Grep utility in C# and I think I can get similar speed to the Rust implementation.
C# is also cross platform as of a couple years ago, as well as is powershell. So my testing was running Powershell on linux against the newest linux kernel source code + the build artifacts.
I think you've kind of already moved the goal posts. Your original comment spoke as if it were factual. But now you're saying "I think it can be done." But you don't know. And on top of that, there have been many greps written in a variety of languages: Go, Python, Perl, Ruby. All of them, that I've tested, are slower than most greps written in C, C++ and Rust. (In some cases, the greps written in Go can be quite fast, but they have very steep performance cliffs that are easy to trip over.)
There are very good reasons to explain this state of affairs.
C# is not something I have a lot of experience with. I don't spend time with Windows-only technologies. C# may technically work on Linux these days, but I don't know of any popular general purpose CLI tooling built with it that works on Unix systems. Why is that? My suspicion is that there are good reasons for it. But if there aren't, then there is a market opening waiting for folks to plow forward.
Basically, I think you are wrong on multiple levels. I think you both under-estimate the difficulty of writing a fast grep and what exactly it takes to do it, and I think you're completely wrong about when Rust is useful. You completely neglect the safety aspect of it, and seem to believe it is not on even footing with C or C++ when it comes to performance. But it most certainly is, in general.
> But I don't think it's the fault of C# and I think it's the fault of some poor coding on redmonds side
Making baseless assertions feels like a pattern that is forming in your comments. Where is Redmond's code? Can you read it and link to me the parts that are "poor"? If not, from whence comes the accusation?
And if you insist with your interpretation of reality, then it follows that I therefore must be a good coder. And if a good coder says to you, "I do not know how to write a fast grep in Go, Python, Perl or Ruby," then why don't you take them seriously?
You keep seeming to come back to "needing the source code.". You know you can reverse engineer a program extremely easily right? Especially a C# one? It's really not the gotcha you think it is. And you can easily see from heuristics that it shouldn't take nearly a minute to gather all the filenames from subdirectories as with GCI. Doesn't take an Einstein to do that.
As for the safety aspect. Can you tell me what Rust means by "Safety"? Alot of Rustacians throw it out, but it really only means "No Undefined behavior". It can help hint at issues, but as someone who writes C code day in and day out, a proper coding technique like SESE can prevent all the issues Rust prevents, and a Static Analyzer like SAL goes far and beyond it. And then with all the icky runtime checks Rust adds, you can't get that in the Kernel, you can't get that "for free". And speaking of reversing your code, it throws in your path names, your file names, and information about the code into each of these. It's definitely not safe opsec wise for a dissident in a dicatorship or an activist!
You also seem to claim C# is "Windows only". Neither C#, nor Powershell, are "Windows Only". C# can run on just the same targets Rust can. WASM, Linux, Windows, etc. You said I wasn't talking about things I was knowledgable on, but despite multiple "hints" on that it's not "Windows Only", you don't seem to want to accept that. It's been the case for years. Being that stale with tech would be retire or fire territory, or just an indicator of incompetence.
And I never said you were a good coder, I said you did a decent job writing RipGrep based off of performance. I personally think from your comments that you have a very small amount of experience with Language design or low level programming, and would not hire you and would put in my review "Does not take hints, is very rude and stubborn."
You call my claims baseless, I went and did testing on the PS commandlets and said they were not fast. I have a program i'm testing right now which matches RG in performance. I'm going to name it "RipGrep But Not Ass". I'll have it on github for you whenever I get the time to finish it. Then you can "Analyze the source code". This conversation is dumb, and you are honestly one of the worst people i've encountered in the coding community.
> You keep seeming to come back to "needing the source code.".
It's important to understand what is being measured. It's not required in the strictest sense, but I am after understanding and without the source, that is difficult. If it doesn't take an "Einstein," then surely you can provide a link either to the source of whatever program you're measuring or some simple instructions for discovering it?
> a proper coding technique like SESE can prevent all the issues Rust prevents
Sigh... So many words on the Internet have been spent on this and related topics, and I do not have the energy to repeat them. If the only education you have on the matter are the words of "Rustacians," then there is plenty more for you to seek out. Maybe start here: https://security.googleblog.com/2022/12/memory-safe-language...
> And then with all the icky runtime checks Rust adds
The only runtime checks ripgrep omits are a few bounds checks deep in the regex engine, and even that gains a 5-10% performance improvement in only some workloads. It would not meaningfully impact ripgrep's overall performance. And yet, ripgrep is faster than GNU grep straight up in many/most cases, which is written in C and lacks your supposed "icky" runtime checks.
> And speaking of reversing your code, it throws in your path names, your file names, and information about the code into each of these. It's definitely not safe opsec wise for a dissident in a dicatorship or an activist!
I'm not aware of any official Rust materials or anyone with any credibility advocating otherwise.
> You also seem to claim C# is "Windows only".
I caveated all such mentions, yet, you seem to ignore them.
> Being that stale with tech would be retire or fire territory, or just an indicator of incompetence.
OK, wow, this conversation has gone to another level. Not really sure what to make of it. I am not retired but gainfully employed. Perhaps I am incompetent, it is not for me to say. Much of the code I have ever written is public, so perhaps you can judge this quality yourself. And if you do, I would love to have any learned critique.
¯\_(ツ)_/¯
> And I never said you were a good coder
I didn't say you did. I specifically and carefully drew an inference, but one you clearly dispute.
> I personally think from your comments that you have a very small amount of experience with Language design or low level programming, and would not hire you and would put in my review "Does not take hints, is very rude and stubborn."
Perhaps you confuse skepticism with rudeness. I am here challenging your claims, of which you have provided zero evidence, but for which I have both published code and published analyses that dispute them. I am glad, though, that my employment does not depend on the whims of random anonymous denizens of the Internet.
> You call my claims baseless, I went and did testing on the PS commandlets and said they were not fast. I have a program i'm testing right now which matches RG in performance. I'm going to name it "RipGrep But Not Ass". I'll have it on github for you whenever I get the time to finish it. Then you can "Analyze the source code".
I'd be happy to analyze it and provide commentary, welcome or not.
> This conversation is dumb, and you are honestly one of the worst people i've encountered in the coding community.
I'm sorry for having troubled you so. I don't mean to come across as rude, although I can see how you might take it that way. I am not really a fan of commentary that states things so certainly but which are contrary to what I perceive to be reality. In so doing, I presented my view of reality and have yet to see a competing version that I can engage with. It is precisely because of that ignorance that I have asked for something that I am able to engage with. I cannot, without expending more resource than I care to, engage with something that is Windows-only or requires a Windows environment to test in. I did not mean to say that what you were doing had those requirements, but meant to merely state what my requirements for engaging were. The point of being clear is not only for me to avoid wasting my time, but for you to avoid wasting yours.
But, I would be happy to do so on my Linux machine if it's possible and update my version of reality. Surely, given that I know little of C#, there is much for me to learn. I note though, that your original comment mentioned several languages other than C#, and my original response did not call out C# specifically. The reason being, of course, that I acknowledge my ignorance of that technology. (And have done so in this conversation before this comment.) Even at the risk of labels of incompetence or staleness from HN commentators.
Why would you compare C#/pwsh PCRE with somethign that is not PCRE and hence has different features. Compare with rg that has --pcre option set if you want to get real comparison.
Why wouldn't you? The other poster hasn't even said which regex engine or which tool they're measuring.
PCRE is absolutely a competitor to Rust's regex crate and it makes sense to compare them.
If all you're doing is measuring the time it takes to find `foo` or `\w+_foo`, then the specific regex engine being used is just an implementation detail.
I'm not saying that using --pcre2 is wrong. It is certainly a useful comparison. But using the default regex engine when the task is "measure a grep" is certainly not wrong either.
Grep is a performance sensitive program, it's not unusual to scan through thousands of files and millions of lines so small inefficiencies are noticeable.
If you tried this in python it would probably take hours to scan through something that ripgrep does in a few seconds
Rust is genuinely only useful for the niche application of a desktop application, that doesn't reach low level, but you need a bit more fine grain controls than C# or another higher level language will allow. For example, a web browser is like the ideal usecase for Rust, and it makes sense, since that's really where it's got most of it's teeth with Mozilla.
I personally don't see why you would do something like Grep, in Rust, when C#, Python, Go, exist. But I do see like Unreal Engine or again, Firefox/webbrowser in Rust being nice.