I haven't benchmarked them, but fd has a recursive parallel directory iterator. ag doesn't.
The mysql-server repository[1] should be a fun one to try out, because of this:
$ wc -l .gitignore
3122 .gitignore
The combination of fast glob matching[2] and parallel traversal should be a boon.
[1] - https://github.com/mysql/mysql-server
[2] - https://github.com/BurntSushi/ripgrep/blob/e7c06b92fb996adcb...
In Show HN: A simple, fast and user-friendly alternative to find, written in Rustmysql
mysql-server
C++2017–2026
mysql / mysql-server
mysql-server
MySQL Server, the world's most popular open source database, and MySQL Cluster, a real-time, open source transactional database.
25Distinct people
29Mentions
0Explicit recommenders
12.5KGitHub stars
What to know before exploring
What it is
MySQL Server, the world's most popular open source database, and MySQL Cluster, a real-time, open source transactional database.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- mariadb/server · linked in 4 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:56:55 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year29 dated mentions
Observed mentions: 2017-04-10 02:00:22 UTC to 2026-01-31 19:01:27 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 1 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Copyright (c) 2000, 2026, Oracle and/or its affiliates.
This is a release of MySQL, an SQL database server.
License information can be found in the LICENSE file.
In test packages where this file is renamed README-test, the license
file is renamed LICENSE-test.
This distribution may include materials developed by third parties.
For license and attribution notices for these materials,
please refer to the LICENSE file.
For further information on MySQL or additional documentation, visit
http://dev.mysql.com/doc/
For additional downloads and the source of MySQL, visit
http://dev.mysql.com/downloads/
MySQL is brought to you by the MySQL team at Oracle.
Read the full README on GitHubWhat Hacker News says
4 sources> Those are things that you can do just as well in C. [..] But the benefit is not "speed", but "speed plus security".
But nobody said otherwise? I don't understand your point. Speed + safety is indeed precisely the point. I would implore you to do your own comparative analysis by looking at the types of bugs reported for these search tools. (I can't do this for you. If I could, I would.)
> What makes ripgrep fast (AFAIK) is mainly using mmap() instead of open()/read() to read files,
I think you're confused. This is what the author of the silver searcher has claimed for a long time, but with ripgrep, it's actually precisely the opposite. When searching a large directory of files, memory mapping them has so much overhead that reading files into intermediate fixed size buffers is actually faster. Memory maps can occasionally be faster, but o
Read the rest
nly when the size of the file is large enough to overcome the overhead. A code repository has many many small files, so memory maps do worse. (N.B. My context here is Linux. This doesn't necessarily apply to other operating systems.)
> and relying on Rust's regex library that compiles regexes to DFAs which can run in linear time.
There's no confusion that such things can't be done in C. GNU grep also uses a lazy DFA, for example, and is written in C.
The "linear time" aspect doesn't show up too often, and none of my benchmarks[1] actually exploit that.
There's a lot more to the story of how ripgrep beats the silver searcher. "About as fast" is fairly accurate in many cases, but to stop there would be pretty sad because you'd miss out on other cool things like:
- SIMD for multiple pattern matching
- Heuristics for improving usage of memchr
- Parallel directory iterator (all safe Rust code)
- Fast multiple glob matching
In many cases, this can make a big difference. Try searching the MySQL server repository, for example, and you'll find that the silver searcher isn't "about as fast" as ripgrep. (Hint: Take a peek at its .gitignore file.[2] This has nothing to do with memory maps, SIMD or linear time regex engines.)
And yes, I could have done all of this in C. But it's likely I would have given up long before I finished.
[1] - http://blog.burntsushi.net/ripgrep/
[2] - https://github.com/mysql/mysql-server/blob/5.7/.gitignore
As I pointed out at https://news.ycombinator.com/item?id=14169188 , there's a discussion of MySQL on the systemd-devel mailing list right now. Clearly some people in that discussion are not familiar with MySQL. Clearly some of the people in this discussion are not familiar with MySQL either.
To help combat this ignorance, here are some actual systemd units:
* https://github.com/MariaDB/server/blob/10.1/support-files/ma... -- MariaDB's official systemd service unit, 173 lines long
* https://github.com/mysql/mysql-server/blob/5.7/scripts/syste... -- MySQL's official systemd service unit, 60 lines long
* https://github.com/percona/percona-server/blob/5.7/scripts/s... -- Percona's official systemd service unit, 61 lines long
* https://sources.debian.net/src/apache2/2.4.25-3/debian/apach... -- Debian's third party systemd service unit for Ap
Read the rest
ache2, 15 lines long
So these figures that people are pulling out of thin air are erroneous by anywhere from half the actual length to an order of magnitude too small. And, ironically, the Apache systemd service unit is using a System 5 rc shell script under the covers to do all of the work. The apachectl program is in fact a System 5 rc script from 1997, complete with start/stop/restart/status verbs.
I was also confused about algorithmic skill and software engineering skills. But I got clarification after working in industry for a while.
1) Most of the software engineering work is product development, just wrapping already existing algorithm and optimized computer program into apis and test and maintain it.
2) There are very few software engineering work involving writing algorithm and optimized computer program.
One example, everyone here might have just used mysql database. But if you look into the code, you might see there are complex data structure, and algorithm are being used.
https://github.com/mysql/mysql-server
Its a good thing to solve these kind of algorithmic problems.
In Visual explanation of the last Google Codejam 2017 question