sahilm

sahilm/fuzzy

Go MIT Dev Tools

Go library that provides fuzzy string matching optimized for filenames and code symbols in the style of Sublime Text, VSCode, IntelliJ IDEA et al.

1.4k stars
66 forks
recent
GitHub

1.4k

Stars

66

Forks

3

Open issues

12

Contributors

v0.1.3 11 Jun 2026

AI Analysis

A Go library providing fuzzy string matching optimized for filenames and code symbols, matching the behavior of Sublime Text, VSCode, and IntelliJ IDEA. It's specialized for interactive search scenarios requiring fast, ranked results with match position data. Best suited for developers building code editors, IDEs, file finders, and command-line tools—not a general-purpose string library.

Dev Tools Library Discovery value: 6/10
Documentation 8/10
Activity 9/10
Community 8/10
Code quality 8/10

Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.

Overall score 8/10

AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.

fuzzy-search string-matching go-library editor-tools performance-optimized
Actively maintained Well documented MIT licensed Niche/specialized use case Beginner friendly Production ready
Deep Analysis · Based on README and public signals
2w ago

Specialized Go fuzzy matching library for editor-style symbol and filename search

sahilm/fuzzy is a Go library providing fuzzy string matching optimized for filenames and code symbols, matching the behavior of Sublime Text, VSCode, and IntelliJ IDEA. It is external-dependency-free and advertises millisecond performance on datasets up to 60K items. Adoption appears limited to Go developers building search features or IDE-like tools; mainstream visibility is low relative to ecosystem-wide fuzzy matching solutions, but the library serves a specific, well-defined niche.

Origin

Created in October 2017 by Sahil Muthoo. The algorithm derives from Forrest Woods' reverse-engineered Sublime Text fuzzy matching work. The project has remained relatively stable, accumulating 1,432 stars over 9 years with modest, consistent maintenance rather than explosive growth.

Growth

Stars increased slowly and plateaued around 1,400–1,432 over the past several years. No stars gained in the last 7 days (as of 2026-06-28). Growth reflects steady adoption within a specific use case (Go-based tools needing fuzzy search) rather than expansion into broader markets. Typical pattern for mature, niche libraries that solve a concrete problem without pretense to general dominance.

In production

Adoption not verified. README includes a demo using Unreal Engine 4 and Linux kernel file listings (example datasets), but does not name known production users or projects. No documented case studies or integration examples. Benchmarks provided (30ms for 60K items) suggest suitability for interactive search, but actual deployment context is unclear. The library is discoverable and downloadable, but concrete usage signals are absent.

Code analysis
Architecture

Appears to be a single-purpose library exporting functions (Find, FindFrom, FindFromIter) and variants (NoSort) for fuzzy matching. Based on README, it operates on strings or via a Source interface and returns matches with position metadata for highlighting. Likely uses a scoring system based on character adjacency, camelCase, separators, and first-character alignment. No dependency on external packages beyond Go stdlib.

Tests

Not documented in README. CI/CD workflow badge shown (GitHub Actions), suggesting tests exist, but coverage metrics not disclosed.

Maintenance

Last push 2026-06-24 (4 days before analysis date), indicating active maintenance. Build status badge present and linked to GitHub Actions workflow, suggesting automated testing is configured. No apparent abandonment; however, the infrequent star growth and modest issue/PR activity suggest this is stable, low-churn code rather than a rapidly evolving project. Typical pattern for libraries that have solved their problem and require only occasional updates.

Honest verdict

ADOPT IF: You are building a Go application or tool that requires interactive, editor-style fuzzy search over filenames or code symbols and you want a lightweight, no-dependencies library with proven performance on 10K–100K item datasets. AVOID IF: You need a general-purpose fuzzy matching algorithm that handles arbitrary data types, requires extensive customization of scoring rules, or your use case is heavily latency-sensitive beyond the 30ms benchmark (e.g., searching millions of items per query). MONITOR IF: You are considering fuzzy matching in Go and want to compare this against lighter-weight alternatives or are unsure whether the editor-specific scoring rules match your user expectations; benchmarking against your dataset is advisable before committing.

Independent dimensions

Mainstream potential

3/10

Technical importance

6/10

Adoption evidence

2/10

Risks
  • Adoption not verified: no documented production users means risk profile for reliability and maintenance responsiveness is unclear.
  • Limited scoring customization: the library enforces a specific ranking model based on camelCase, separators, and adjacency; if your use case requires different ranking criteria, you may need to fork or seek alternatives.
  • Performance scale unknown: benchmarks provided for 16K and 60K items; behavior on much larger datasets (millions) is not documented, raising uncertainty about real-time search at scale.
  • Niche ecosystem: few downstream projects or integrations visible, meaning community support and third-party extensions are limited; contributors are sparse.
  • No versioning discipline documented: README does not specify semantic versioning or breaking-change policy, creating uncertainty around stability guarantees across Go module versions.
Prediction

This library will likely remain stable and modestly maintained for Go developers needing editor-style search. Mainstream adoption outside the Go ecosystem is improbable given its language-specific nature and narrow design scope. Slow growth is expected to continue; the project has found its niche and shows no signs of either explosive adoption or abandonment.

0 found this helpful

Newsletter

Get analyses like this every Monday

Free weekly digest of the most interesting open-source discoveries.

Languages

Go
94.1%
Makefile
5.9%

Information

Language
Go
License
MIT
Last updated
2w ago
Created
106mo ago
Analyzed with
anthropic/claude-haiku-4-5

Stars over time

Loading…

Contributors over time

Top 100 contributors only — repos with more will plateau at 100.

Loading…

Similar repos

junegunn

junegunn/fzf

fzf is a general-purpose command-line fuzzy finder written in Go, distributed...

81.6k Go Dev Tools
fatih

fatih/vim-go

vim-go is a comprehensive Go language development plugin for Vim and Neovim,...

16.2k Vim Script Dev Tools
onsi

onsi/gomega

Gomega is a matcher library for Go testing, specifically designed as Ginkgo's...

2.3k Go Dev Tools
sohaha

sohaha/zlsgo

zlsgo is a lightweight, modular Go utility library providing web framework...

1k Go Web Dev
visualfc

visualfc/liteide

LiteIDE is a lightweight, cross-platform IDE specifically designed for Go...

7.8k C++ Dev Tools
vs. alternatives
junegunn/fzf

57x larger (81K stars vs 1.4K). fzf is a standalone CLI tool and shell plugin for fuzzy finding files/commands; fuzzy is a Go library for programmatic matching. Different use cases: fzf serves end-users and shell scripts; fuzzy serves developers embedding search in Go applications. fzf is more visible but solves a different problem.

Sublime Text built-in search

fuzzy reimplements the algorithm from Sublime's closed-source fuzzy matching, making it portable to Go applications. Not a direct competitor since Sublime is an editor; fuzzy is a library. Compatibility with Sublime's matching style is the design goal, not displacement.

VSCode search API

VSCode's search is built-in to the editor and implemented in TypeScript/Electron. fuzzy is a standalone Go library. Not directly comparable; fuzzy may be used by Go tools that want VSCode-like search semantics without depending on VSCode itself.

ripgrep (rg) search

ripgrep focuses on regex-based content search in files; fuzzy is for interactive fuzzy matching of strings. Different problem domains. Complementary rather than competitive.

Generic Go string search libraries

Many string-matching libraries exist (e.g., Levenshtein, jaro-winkler). fuzzy is specialized for the editor-search use case (symbols, filenames, camelCase aware). More specific than general-purpose alternatives but narrower in scope.