This is really my hope too. Julia still has a number of unresolved tradeoffs, but they are not inherent any more than the performance/productivity tradeoff that Julia has already shattered are. They may be fixable but they are not easy to fix.
The first tradeoff that Julia really needs to tackle is the JIT latency one. Lots of work has been done here but I think what will really “fix” it will be having a tiered JIT where an interpreted version of code starts executing immediately until a fast compiled version of that code is available. Work on that is already starting to happen (lazy LLVM JIT being the first step). It will be accomplished incrementally in the sense that even when it’s mostly solved it probably still won’t include some of the fancier tiered JIT features like on-stack replacement of code running in the interpreter with the same code running optimized. In the fullness of time, if it seems beneficial, all the bells and whistles can be added.
The next tradeoff is the one here: providing a way to move gradually from loose, interactively developed code that may not be fully correct in all corner cases to code that can be shown to be correct and not error in various ways. Rust includes rules to ensure that kind of correctness in its type system and compiler, but that’s not the only way to do it, as JET shows. My hope here is that JET will be extended and eventually shipped with Julia and can be applied to code to show that it is correct with respect to various desirable properties in an incremental way.