I use effects to make guarantees about what the code will and won't do.
When Option was retrofitted onto Java, the NPEs didn't disappear. We got Options that could be null, but more importantly, devs (and the standard library) continued to use null liberally. We never ended up at the tautological goal of "if I have a Person, then I have a Person".
I am equally skeptical of bolting on effect systems after the fact. Even if one of these effect systems becomes 'the main one' and starts showing up in standard libraries, we'll still end up with declared-effectful code and undeclared-effectful code, but will again fall short of the goal, declared-effectful code.
Doing something a bit vs almost completely can have a significant difference in practice - having a way to maybe avoid nulls doesn't solve the million dollar problem, but making non-nullability the default arguably has (see Rust, Kotlin, etc).
An even better example would be Rust's memory safety. Sure, there is still unsafe, but it being used very sparingly has reached its goal.
So I think a new language where 'pure' is the default (with a few, locally scoped escape hatches), and effects are "mandatory" would actually be pretty effective at reaching its stated goals.
I agree, this seems like something where it really needs to be natively supported in the language from day one to work properly.
The impact of Effects are a bit less pervasive than null wouldn’t you say ? Effects can be used with code “in between” that knows nothing about effects. Performing and handling effects can be quite transparently