Hacker News Reader

I hate to be one of those people that asks “what differentiates this from X”, but is there a selling point for why I’d want to use this over https://github.com/theseus-rs/file-type if I’m in a sync + std context and don’t really care about dependency count?

View on HN

These two crates follow different philosophies. file-type is great for lightweight, static detection. In contrast, `magical_rs` is designed to be a framework — it lets you define custom rules, layer logic via DSLs, and even embed custom function pointers for advanced matching. So if your use-case involves complex formats, edge-case detection, or internal tooling where you need full control — magical_rs gives you the power without forcing you to fork the crate.

I mean, for full control we generally only need a file handle, not a framework. ;)

You are absolutely right if you only need to detect simple file types. But of course no one forks a library to add the 3 file types they need and then re-builds them, and not to mention that because it's a static rule, if you want to detect more complex file types, it almost means you'll have to rewrite the entire core for that.

Reply on news.ycombinator.com