Go's regex is 78x slower than Rust's. Google did it on purpose.

[00:00:00]I benchmarked Go's regex engine against Rust. Same patterns, same 200 megabytes of logs, and the match counts came out identical every single time. The worst [music] case, 78 times slower. And here's the twist that makes this worth 10 minutes of your life. Go is slow on purpose. [music] To see why, you first need to watch a regex commit murder.

[00:00:17]This is a ReDoS, a regular expression denial of service.

[00:00:20]>> [music] >> The pattern looks harmless. One or more A's wrapped in a group that also repeats, then end of line. I hand Python a string of 30 A's and one exclamation mark. And it's gone. At 28 characters, this takes 10 seconds, and every character you add doubles it. 40 characters would run for 11 hours. 64, 21,000 years. Now, the same pattern in Go on 100,000 characters, 4 milliseconds. That's not luck. That's a guarantee.

[00:00:46]Here's what's eating Python alive. A backtracking engine tries possibilities.

[00:00:50]That nested quantifier means every single A can belong to the inner loop or start a new pass of the outer one. So, the tree of ways to split the string doubles with each character. When the match finally dies at the exclamation mark, the engine crawls back and tries every other split. 28 characters in, that's over a quarter of a billion paths. This [music] is the explosion.

[00:01:10]Google's answer was RE2, and it's what Go ships as the standard library. It never backtracks because it is never trying paths in the first place. The pattern becomes a state machine, and that [music] machine gets dragged across your input exactly once, one step per byte, no matter how evil the pattern is.

[00:01:25]Worst case equals best case. Go looked at a 40-year-old foot gun and simply deleted it. Genuinely, respect.

[00:01:32]So, that's the defense, and it's a good one. But, somewhere along the way, we chose safety became the permanent excuse for something else, because that same one-pass design exists in Rust with the same guarantee and the same immunity to the explosion you just watched. So, let's race them. Honestly, same file, same patterns, and the output has to match to the last digit.

[00:01:51]The entire Rust program, take a pattern from the command line, read 200 megabytes of logs into one string, compile the regex, count every match, print [music] the count. A dozen lines, nothing clever, no unsafe, no tricks.

[00:02:03]The regex crate does all the work.

[00:02:06]And Go. The same job, almost character for character. Read the file, compile the pattern, count the matches.

[00:02:13]Honestly, the Go version is the nicer one to type. Both programs print their match count, and across every test in this video, those counts agreed exactly.

[00:02:21]Same work, same answers. Now, the clock.

[00:02:24][music] First, real pattern. Find every email address in the logs. Rust, [music] done.

[00:02:30]A fifth of a second, and most of that was just reading the file off disk.

[00:02:34]225,694 matches. Now, Go. Same regex, same file.

[00:02:39]And now, we wait. The cursor isn't stuck. This is the design working exactly as intended. 7 seconds. And there it is, the identical match count to the digit. The answers match. The bills [music] don't.

[00:02:53]Under hyper fine, warmed up, and averaged over runs, it stops being a feeling and becomes a number. Rust, 102 milliseconds. Go, 6.8 seconds. 67 times.

[00:03:04]Look at the left panel. In the time Go needs to scan the file once, Rust has already rerun the entire job 66 more times.

[00:03:11]>> [music] >> And it's not one cherry-picked regex. A plain literal string, three times faster. A bounded repeat, the shape of every access key scanner, 11 times. The email pattern, 67. And a case-insensitive alternation, the bread and butter of every log search ever written, 78 times faster. Same guarantee on every row, identical counts on every row. The gap grows exactly where regexes get useful.

[00:03:33]>> [music] >> Let's make it hurt. 1 GB of logs, five error keywords, case-insensitive. Rust, 2.3 seconds. Done before you've settled into your chair. Go's [music] turn. And I'm going to fast forward here because nobody has time for the raw footage. A minute, 31.7 seconds for the identical 938,000 matches. [music] If this scan runs hourly in your pipeline, that gap is not a benchmark anymore. It's your compute bill.

[00:03:57]>> [music] >> So, how is the same guaranteed this much faster?

[00:04:03]Two reasons, both pure engineering. Rust builds the state machine lazily and caches it. So, the hot loop is a tight DFA sprint. And before that loop even runs, Cindy pre-filters chew through memory 16 bytes per instruction, skipping straight to the only places a match could possibly start. Go walks its automata on one byte at a time, and Go's compiler will not vectorize that walk.

[00:04:23]Same idea on paper, wildly different execution.

[00:04:27]And before you ask if Rust paid for this with safety, the exact pattern that hung Python on 100,000 characters in Rust under 100 nanoseconds. The guarantee survived the speed.

[00:04:40]Full credit where it's due. Go shipped regex safety as the default when almost nobody else would, and its engine still compiles patterns fast, [music] which matters when you build regexes on the fly. But, Rust's regex crate has carried the exact same linear time guarantee for about a decade, while being one to orders of magnitude faster at actually matching. Safety was the reason. At some point, it quietly became the excuse.

[00:05:03]So, here's my actual take.

[00:05:05]Using Go's [music] regex B is completely fine right up until the input grows six zeros. If you grep logs, scan requests, or filter events at real volume, then safe but 78 times slower is a decision someone made for you in 2012, and you're still paying the invoice.

[00:05:20]Rust made the other decision, keep the guarantee, then spend 10 years making it fly. Safety versus speed was never the trade-off.

[00:05:27]It was the excuse.

[00:05:29]Every number in this video came off my laptop. The programs, the logs, and the measurements are real, and the match counts agreed on every single run. If you want more experiments where the receipts actually exist, subscribe.

[00:05:40][music] I run these so you don't have to.