Ah okay, thanks 👍🏻

Why is the resulting rust code only slightly safer? Rust as a language is a lot more memory safe than C. If you’re talking about current transcompilers, then improving those should lead to improvements in C.

Okay the links are clearly not on the page itself. You can see at the top that the UI is clearly distinct from the website itself and is more like a feature of the browser than anything else. As far as I can see, it’s just a convenient way of displaying search results for the headline without the user having to manually search it themselves.

And well, that’s really a strawman argument since that is not at all what Google is doing here. Equating a news site and the website of a corporation that sells actual products isn’t really meaningful.

Really, it’s like berating Spotify for having their radio feature because it can show me similar songs to the one I’m listening to. It’s a feature that doesn’t really hurt anyone, and on the contrary, benefits the majority of people. I’m sure Tyler’s fine with Spotify playing some Frank Ocean on his radio.

Minor comment is that the codebase doesn’t need to fit into ram for you to hash it. You only need to store the current state of the hash function and can handle files X bytes at a time.

I can’t say what the parent meant, but my thought is that a blessed way to lay things out and build should ship with the primary tooling for the language, but should be implemented and designed with extensibility/reusability in mind, so that you can build new tools on top of it.

The idea that compilation shouldn’t be a special snowflake process for each language is also good. It’s a big problem space, and there may well not be one solution that works for every language (compare javascript to just about anything else out there), but the amount of duplication is staggering.

Considering how big compilers/stdlibs are already, adding a build system on top would not make that much of a difference.

The big win is that you can download any piece of software and build it, or download a library and just add it to your codebase. Compare with C/C++ where adding a library is often more difficult than writing the code yourself, because you have to figure out their (often insane) build system and integrate it with your own, or figure it out then ditch it and replace it with yours

Hashing file contents should be disk-io-bound; a couple of seconds, at most.

You could always do a hybrid approach: do the hash check only for files that have a more-recent modified timestamp.

It’s a plain Lua script that does host detection and converts lines like bin( "asdf", { "obj1", "obj2", ... }, { "lib1", "lib2", ... } ) into make rules.

One shouldn’t have to consider the possibility of getting swatted for contributing to an open-source project.

That’s what I heard too.

Make is a really bad example here, given how much software needs gmake or bsd make and doesn’t support both in practice.

(Also, by the way, one of the reasons why I think it is good that rustc is not built with make anymore)

For a tool like ripgrep, that it is written in a memory safe language isn’t a terribly direct benefit to an end user. In particular, folks don’t usually use the tool in a context where a vulnerability would be that damaging.

With that said, memory safety has other benefits, like (IMO) lower development time. I’ve been maintaining ripgrep for over a year now, and I literally don’t spend time debugging memory related bugs. I don’t just mean “it doesn’t happen that often,” I mean, “it’s never happened, not once.” That’s a lot more time I can put into fixing other types of bugs or adding features. This is good for users, albeit indirectly. Granted, this is probably a pretty lame argument, but I’m just relaying my own experience here as I see it.

This of course varies from programmer to programmer. A better C or C++ programmer than myself, for example, might not spend any time debugging memory related bugs either. But I’m not that good.

One might also make an argument in favor of using another memory safe language that has a GC, but the onus is on them to show that the tool can actually compete performance wise. I do suspect it is possible, although it hasn’t been done. I’d expect D to be capable, and probably also Go. (There are some ripgrep-like tools written in Go, but they break down once you push them a little harder than simple literal searches. I cannot conclude that this is a breakdown in Go itself because there is missing implementation work to make it run faster. Particularly in the regex engine.)

Saying they’re fast implies that the current implementation is slow

GNU grep isn’t slow in the vast majority of cases. On a single file search, ripgrep might edge it out. As you increase the complexity of the regex (say, by using lots of Unicode features without any literals), then ripgrep starts to get a lot faster (~order of magnitude). In the simpler cases, ripgrep tends to edge out GNU grep by using a mildly smarter heuristic that lets it spend more time in an optimized routine like memchr in common cases. But GNU grep could easily adopt the latter. It would be harder for them to fix their Unicode problems, and probably not worth their time. (Because once you stick a literal into the pattern, it speeds back up again.)

However, if you say “compare default usages of these tools, including recursive search,” then ripgrep is going to toast GNU grep just because it will use parallelism by default. Which makes this a mostly uninteresting comparison if you’re curious about the details of performance difference, but that doesn’t stop it from being a very interesting UX comparison. That’s typically the source of claims like “ripgrep is so much faster than grep,” which are unfortunately also easily interpreted as a really interesting claim which provokes the question, “oh, so what is the interesting implementation choice that makes it faster?” When folks find out that it’s just parallelism or ignoring certain files (that are in your .gitignore), they rightfully feel cheated. :-) Another less common source of this that people use “grep” to refer to both BSD and GNU grep, and BSD grep has markedly different performance characteristics than GNU grep.

Performance is complicated, so if you really want to the dirty details, just skip straight to my analysis: http://blog.burntsushi.net/ripgrep/

Ripgrep is a lot faster than grep for general use; not necessarily because the search algorithm is faster, but because it defaults to ignoring .gitignored files and BLOBs, which usually is what you want.

They “feel modern” is subjective, so I’ll pass on that point. Saying they’re fast implies that the current implementation is slow, and is “written in a memory-safe language” really an advantage of a program being written in a memory safe language? Seems a little circular.

The parent said “they feel modern, are fast”, not “they feel modern, are fast_er_”. The point is that they are on par, not that the current state is “slow”.

I’m by no means an expert so my opinion doesn’t count for shit and so I take no sides in this, but it seems like the OP made a bunch of really good points that need addressing, and this really doesn’t.

Given that around here, there’s a discussion on how people can’t find out what the OP exactly meant, I find this statement a bit confusing.

ripgrep does exactly that when you use it in a pipeline. When you print to a tty, it uses a “prettier” format. If you don’t like the prettier format, the --no-heading will force the more traditional format. Put it in an alias and then forget about it.

‘modern’ often means forgotten knowledge

And is also often a good thing. Compare and contrast POSIX grep’s and ripgrep’s support for Unicode, for example. ripgrep “forgets” a lot of stuff and just assumes UTF-8 everywhere. This works well enough in practice that I’ve never once received a complaint. Well, that’s not true. I did receive one complaint: that ripgrep can’t search UTF-16 files, which are not uncommon on Windows. But I fixed that by adding a bit of code to ripgrep that transcodes the corpus from UTF-16 to UTF-8 when a UTF-16 BOM is detected, and hey, it works! But if I didn’t “forget” about POSIX, then that might not have been possible at all.

This comment should not be interpreted as an argument against POSIX, OpenBSD’s (or any other OS) use of it. Instead, I’d like you to interpret it as a criticism of the myth that “the good ol’ days” ever existed at all. My bottom line is that history has a lot to teach us, and just because we don’t copy it exactly as it was doesn’t mean it was forgotten. Sometimes mistakes are made, or perhaps even more frequently, technology simply changes and evolves that makes repeating historical choices a hard pill to swallow in some contexts.

So how about instead of focusing on “forgotten” knowledge (and, to the same extent on the other end of the spectrum, avoid the new and shiny—but I’m speaking to a certain audience here so I’ve omitted that) we just focus on the problem we’re trying to solve instead? If there’s some ancient (or new, I don’t care) wisdom that I don’t know about that could make ripgrep a better tool, then I’m all ears.

Also, I’ve never once marketed ripgrep as “modern.” ;-)

Are you sure? I’m not at the computer right now, but IIRC it outputs exactly like that when it’s writing to a pipe, not a terminal. Try piping into less.

Also: process crashes, core dump gets written with secrets inside of it, adversary gets access to disk.

Suspend sounds like a good use case. I might have to patch some go code I have.

Maybe add “code ran in VM that moved” to 4 depending on whether whatever manages them overwrites memory before dropping a new one. This could become a bigger risk for platforms that use lightweight VM’s/containers with rapid launch and shutdown.

I agree that encrypting secrets is the next logical step. I’ve been planning a scheme for a while now and it should hopefully land in the next major update, time permitting.