Minor thing, I find it off putting when a project describes itself as “one of the best frameworks”. Just launch straight into the offering and let users decide. You already have multiple selling points, no need for the blatant self promotion.
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?
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.
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.
I think it could utilise somehow the file(1) database (/usr/share/misc/magic.mgc, /usr/share/misc/magic), it has lots of file formats detections already, although the format itself is a little limited.
Minor thing, I find it off putting when a project describes itself as “one of the best frameworks”. Just launch straight into the offering and let users decide. You already have multiple selling points, no need for the blatant self promotion.
You're right – that phrase was a bit much. I'll revise it. Thanks for pointing it out!
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?
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.
I think it could utilise somehow the file(1) database (/usr/share/misc/magic.mgc, /usr/share/misc/magic), it has lots of file formats detections already, although the format itself is a little limited.
[dead]
[dead]