"Structural vs nominative debate aside, you might have noticed a major omission in the data model: closures"
Then goes on to explain that they would be hard to serialize.
Not so. If you take at how ruby handles closure members when serializing with Marshal.dump, you will see that it just writes a memory address and doesn't actually store a call graph. So why not just omit it like ruby does?
Is Ruby able to deserialize the closure into the same process that serialized it? In any case, it won't be able to do that in a different process; e.g. if the data is sent over the wire.
I think the approach of not allowing closures in data that may have to be serialized is a much better approach than just writing a memory address and leaving the recipient to deal with the problem.
A "simple rule" that's not programmatically enforced is just a convention, and conventions are too easily ignored. I'd be ok with a type-system based solution that distinguishes serializable and non-serializable types, but silently writing nondeserializable data is just asking for trouble down the road.
This language in particular is built around having value semantics for everything (e.g. writing to a database and reading back is guaranteed to result in an indistinguishable value); and that enables nice features like persisting the complete application state on disk, deterministic replay of logs and so on.
I think for the goals of this language, disallowing closures as data is a reasonable choice.
Then goes on to explain that they would be hard to serialize.
Not so. If you take at how ruby handles closure members when serializing with Marshal.dump, you will see that it just writes a memory address and doesn't actually store a call graph. So why not just omit it like ruby does?