ArkType type matcher vs Effect Match module
Hello, wanted to discuss the newly released type matcher and how would it differ from the Effect Match module. I know Effect Match module has a couple of limitations in the way it works and I'm also not sure arktype type matcher and Effect Match are up for comparison, based on their goals. So just wanted to reach out and see if anyone's wondering the same and if some of you have some answers and comparisons already. Thanks!
1 Reply
I haven't had a chance to compare them directly yet. My guess is the comparison in some ways would be similar to ts-pattern. Here's the answer I gave for questions about that:
It's a totally different approach with different trade-offs. With ArkType, you create a matcher up front using type syntax, where it's parsed and optimized. Then when you invoke it later, it's super fast with great error messages (the announcement post actually gives a comparison to ts-pattern). This kind of technique is especially good for e.g. server code where initialization is cheap and you can benefit from the faster execution many times. ts-pattern is a great library and has lots of match-specific features we don't yet support and may never support. Plus if you're only going to run the matcher a couple times, ArkType's optimized matching will be outweighed by the upfront initialization cost.The initialization techniques w/ JIT optimization + set-based comparisons are very unique, but that trade off isn't always worth it depending on whether your matcher is running many times or not. In reality it's a relatively small wrapper around ArkType's core type system, which has pros and cons. The pros are that it benefits from all those error messages, introspectability and optimization. You can use any definition you can use to define a Type to define a matcher. The cons are that there are relatively few match-specific utilities at this point and the mentioned intialization cost. Another big trade off is the ability to statically validate exhaustiveness, because the impact on type-level performance throughout the rest of ArkType to track subtype constraints (e.g. string.email or number > 5) was too extreme when it was only really impactful from within pattern matching.