The regex that breaks Go
You copy a regex pattern from a Python script. It works perfectly. You paste it into Go. The build fails. The error message mentions invalid or unsupported Perl syntax. You stare at the pattern. It uses (?=...). You think Go is missing a feature. You think Go is broken.
Go is not broken. Go made a deliberate choice. The regexp package does not support lookahead or lookbehind assertions. It also lacks backreferences and some other advanced features found in Perl, Python, JavaScript, and Ruby. This restriction comes from the underlying engine. Go uses RE2, a regex engine designed for speed and safety. RE2 guarantees linear time execution. It never backtracks. It never gets stuck. To keep those guarantees, RE2 drops features that require guessing and jumping around the text.
Why lookaheads break the rules
Regex engines fall into two categories. The first category uses backtracking. These engines try to match a pattern by exploring paths. If a path fails, the engine jumps back to a previous position and tries a different path. This approach supports lookaheads, lookbehinds, and complex nesting. It also supports catastrophic backtracking. If the input text has a repeating structure that almost matches but fails at the end, the engine can loop exponentially. A crafted input can freeze a server for hours. This is called a regex bomb or ReDoS.
The second category uses finite automata. These engines convert the pattern into a state machine. The machine reads the input once from left to right. It never jumps back. It never tries alternative paths. The time to match is proportional to the length of the input. The engine finishes quickly, even on malicious input. RE2 belongs to this category.
Lookaheads require the engine to jump ahead, check a condition, and return to the original position without consuming text. That behavior breaks the one-pass rule. If RE2 supported lookaheads, it would need to backtrack or maintain complex state that destroys linear time performance. Go prioritizes predictable performance over regex flexibility. You cannot peek ahead, but your regex never hangs.
Minimal example: the error and the fix
When you use a lookahead in Go, the compiler rejects the pattern. If you use regexp.MustCompile, the program panics at startup. If you use regexp.Compile, the function returns an error.
package main
import (
"fmt"
"regexp"
)
func main() {
// This pattern uses a positive lookahead.
// Go's regexp package rejects it immediately.
// The error is: error parsing regexp: invalid or unsupported Perl syntax: (?=
re, err := regexp.Compile(`foo(?=bar)`)
if err != nil {
fmt.Println("Regex failed:", err)
return
}
fmt.Println(re.MatchString("foobar"))
}
The output shows the error. The pattern foo(?=bar) asks the engine to match foo only if bar follows. RE2 cannot do that. The fix is to match the context explicitly. If you need foo followed by bar, match foobar. If you need to extract foo but verify bar exists, match both and extract the part you want.
package main
import (
"fmt"
"regexp"
)
// ExtractFoo checks for foo followed by bar.
// It matches the full context and extracts the target.
func ExtractFoo(text string) string {
// Match foo followed by bar.
// Capture foo in group 1.
re := regexp.MustCompile(`(foo)bar`)
matches := re.FindStringSubmatch(text)
if matches == nil {
return ""
}
// matches[1] holds the captured group.
return matches[1]
}
func main() {
fmt.Println(ExtractFoo("foobar")) // foo
fmt.Println(ExtractFoo("foobaz")) // ""
}
Match the context. Extract the value. Skip the lookahead.
Realistic example: log parsing with context
A common use case for lookaheads is filtering. You want to match a timestamp only if the log line contains ERROR. In Python, you might write (\d{4}-\d{2}-\d{2})(?=.*ERROR). Go requires a different approach. You match the timestamp and the ERROR keyword in one pattern. You capture the timestamp. You ignore the rest.
package main
import (
"fmt"
"regexp"
)
// ExtractErrorTimestamp finds the date from an error log line.
// It avoids lookaheads by matching the surrounding text explicitly.
func ExtractErrorTimestamp(line string) string {
// Match timestamp, then any characters, then ERROR.
// Capture the timestamp in group 1.
// The .* between timestamp and ERROR is safe in RE2.
re := regexp.MustCompile(`(\d{4}-\d{2}-\d{2}).*ERROR`)
matches := re.FindStringSubmatch(line)
if matches == nil {
return ""
}
return matches[1]
}
func main() {
lines := []string{
"2023-10-01 INFO request completed",
"2023-10-01 ERROR connection refused",
"2023-10-02 WARN low memory",
}
for _, line := range lines {
ts := ExtractErrorTimestamp(line)
if ts != "" {
fmt.Printf("Error on %s: %s\n", ts, line)
}
}
}
The output prints the error line with the timestamp. The pattern (\d{4}-\d{2}-\d{2}).*ERROR matches the whole line structure. The capture group isolates the date. This approach is slightly more verbose than a lookahead, but it runs in linear time and works in Go.
RE2 runs in linear time. Your regex never hangs.
Pitfalls and compiler errors
Go's regex errors appear at compile time or runtime depending on how you create the regex. regexp.MustCompile panics if the pattern is invalid. Use it for patterns hardcoded in your source. regexp.Compile returns an error. Use it for patterns from user input or configuration files.
Common errors include:
error parsing regexp: invalid or unsupported Perl syntax: (?=when you use lookaheads or lookbehinds.error parsing regexp: missing argument for repetition operator: *when you write*without a preceding element.error parsing regexp: invalid nested repetition operator: ++when you chain quantifiers like++or**.error parsing regexp: missing closing ) for group starting at ...when parentheses are unbalanced.
If you use MustCompile with a bad pattern, the program crashes with a panic. The panic message includes the error text. This is useful during development. It forces you to fix the pattern before the code runs. In production, use Compile for dynamic patterns. Handle the error gracefully.
// ValidatePattern checks if a user-supplied regex is valid.
// It uses Compile to avoid panics on bad input.
func ValidatePattern(pattern string) error {
// Compile returns an error if the syntax is invalid.
_, err := regexp.Compile(pattern)
return err
}
Convention aside: the community prefers if err != nil { return err } for error handling. It makes the unhappy path visible. Don't swallow errors from Compile. If the pattern is bad, the caller should know.
MustCompile for constants. Compile for variables. Panic only on bugs.
Workarounds for lookahead logic
When you need lookahead behavior, restructure the logic. Go offers several strategies.
Match the full context and extract. This is the most common workaround. Write a pattern that includes the lookahead condition as part of the match. Use capture groups to isolate the data you need. This works for positive lookaheads. For negative lookaheads, match the pattern and verify the condition in Go code.
Split the work into multiple passes. If the logic is complex, use regex for extraction and Go code for validation. Extract candidates with a simple regex. Filter them with string functions or conditional logic. This keeps the regex simple and moves complexity to readable code.
Pre-process the text. If you need to match based on surrounding context, transform the text first. Add markers or split the text into chunks. Then apply a simpler regex to each chunk. This is useful for structured data like CSV or JSON lines.
Use strings functions for simple checks. If you only need to verify that a substring exists, strings.Contains is faster and clearer than regex. Regex adds parsing overhead. Use it when you need pattern matching, not literal search.
package main
import (
"fmt"
"regexp"
"strings"
)
// FindUserWithRole extracts usernames that have a specific role.
// It uses a two-pass approach: extract candidates, then filter.
func FindUserWithRole(log string, role string) []string {
// Step 1: Extract all usernames.
// Match "user:" followed by word characters.
re := regexp.MustCompile(`user:(\w+)`)
matches := re.FindAllStringSubmatch(log, -1)
var result []string
for _, match := range matches {
username := match[1]
// Step 2: Check if the role appears in the same line.
// This simulates a negative lookahead by filtering in code.
if strings.Contains(log, "role:"+role) {
result = append(result, username)
}
}
return result
}
func main() {
log := "user:alice role:admin user:bob role:user"
admins := FindUserWithRole(log, "admin")
fmt.Println(admins) // [alice]
}
Simple string functions beat regex for simple strings. Regex wins when the pattern is complex. RE2 wins when the input is untrusted.
Decision: when to use regex vs alternatives
Use regexp.MustCompile when the pattern is a constant known at compile time and you want a panic on syntax errors during development.
Use regexp.Compile when the pattern comes from user input or configuration, so you can handle invalid syntax gracefully without crashing.
Use strings.Contains or strings.Index when you are searching for a fixed substring; regex adds overhead you don't need.
Use regexp with capture groups when you need to extract structured data from text; match the surrounding context explicitly and pull out the groups you need.
Use a separate validation step when the logic is too complex for a single regex; split the work into multiple passes or use a parser library.
Use regexp/syntax when you need to inspect or transform regex trees programmatically, not just match text.
Trust RE2. It protects you from regex bombs. Match the context. Extract the value. Don't fight the engine.