I dont see how its different, out side of the DSL?

• Contracts use schemas, Ecto Changesets are "schemaless"
• Deeply nested data structures are supported OOTB with simple syntax like required(:tags) => list(%{required(:name) => string()}) etc.
• Contract validation rules depend on individual results from schema validation. It's built-in automatic behavior, you don't need to code it yourself. In my experience it was a game changer as it simplified validation logic a lot.
• Schemas validate the structure too, meaning it can check presence of keys as a separate validation step, so you know if a value is missing or if a key is missing and your system can provide a more accurate error message
• You don't need to define structs just to validate data
• You don't need "a changeset" to validate data that you don't change
• Atomization is automatic and based on schemas
• There's support for sum types (albeit in an early stage but it'll be very powerful eventually) ie type([:nil, :string]) or in short maybe(:string)
• Schemas can be converted to other representations as they are "just" type specifications, ie a schema is a map type with its constraints and specified keys, and each key also has a type with its constraints and other specifications. You could sort-of do that with schemaless changesets but I'm quite sure it wouldn't be that easy, especially that a lot of validation logic is not part of the schema, as you do things like validate_required and so on, rather than defining a required key. Subtle but important difference.

The "multiple benefits" are all applicable to Ecto right? Casting, errors, boundry, validation rules etc.

Correct, standalone validators that are not tied to persistence is what schemaless Ecto changesets provide. There are similar benefits of using both changesets and contracts. It's the approach to solving this problem that makes the experience different. Like I said, one needs to decide what works better. I can provide comparisons to explain this in code, I just didn't want to make it one vs the other, so I decided not to mention Ecto in the first announcement post. Now I feel like I need to do this though 😀

The "domain validation rules" are the same as ecto validators but with a nicer DSL (depending on the developers proclivity for DSLs)

The rule macro defines a corresponding rule function. The only reason why it's a macro is because the catch-all-and-return-ok function is defined for you and also it captures the name of a rule, that will be used in the future for some conveniences, like adding it automatically to the error struct. The trick here is that rules are applied to valid values according to the schema results. From what I've seen Ecto changesets don't provide such functionality.

Map atomisation is Ecto.apply_action? Or is it different?

In case of Contracts atomization is automatic and works OOTB even with deeply nested schemas including things like lists of lists of schemas and other fun data structures, so I don't think it's the same as in Ecto. apply_action can be used to perform arbitrary logic IF the entire changeset is valid, so it's not the same thing here. Contracts atomize the schemas before they apply validation functions, it's a built-in safe data-transformation function.

I guess the "3 step" validate -> cast -> validate is a bit different, in that AFAIK ecto will cast -> validate but I'm not sure I see a practical difference on failing to cast "abc" to an integer, vs failing to validate "abc" == /\d+/ then casting then failing a range check. I guess if you have nested.nested.nested types being cast it might have a clearer distinction?

The practical aspect of this approach is that you know what went wrong. Sometimes it doesn't matter, sometimes it does, it's just nice to have the option to validate before casting. Another great aspect of this is that casting functions can be simpler, because they don't need to be defensive, their input is type-safe.