What are the goals and positioning of pyston given these other efforts?

If packages use generic indexing functions like eachindex, there would be no correctness issue with that specific example

That's exactly where Dex might improve over Julia, with language level control over mutability and effect handlers and array access safety ... time will tell.

So packages just use those features

Maybe it will hit the right trade off, or maybe Julia will adopt similar language level tools, but adjusted for dynamic semantics. Is that even possible?

Please see my comment here: https://news.ycombinator.com/item?id=31269739

Based on the above, I expect more than marginal improvements in these areas. Would you agree?

There are several repeating (valid) critiques. There is also a sense that things won't get better. I don't think that's necessarily the case.

I can't give timelines, but I'll list the themes and point to the very active work going on in those areas:

1. Static analysis/ it's hard to write large codebases of correct Julia code.

That's being addressed on several fronts:

a. Work on both traits/interfaces and sound static typing is progressing in Jan Vitek's group at Northwestern

b. User extensible type lattice for correctness proof of programs. See here: https://news.ycombinator.com/item?id=26136212

c. Jet.jl already catches method errors at JIT time. It's under-used IMO.

2. Compilation time and package dev latency.

a. We're getting close to native code caching, and more: https://discourse.julialang.org/t/precompile-why/78770/8

As you'll also read, the difficulty is due to important tradeoffs Julia made with composability and aggressive specialization...but it's not fundamental and can be surmounted. Yes there's been some pain, but in the end hopefully we'll have something approximating the best of both worlds.

b. Runtime free static compilation: https://www.youtube.com/watch?v=YsNC4oO0rLA

c. Semantics for separate compilation: https://gist.github.com/JeffBezanson/dd86043ef867954bd7e2163...

Some combination of the above should also address deployment scenarios, whether that be CLI, mobile, browser or even embedded (Yes, with an (expanding) subset of code, StaticCompiler can produce binaries down to the 10s of Kbs with real working Julia programs that use non trivial abstractions like subtyping and higher order functions)

3. Zygote is rough

a. Enzyme will do (almost) whole language AD, including mutation.

b. Diffractor.jl

Do you have a link to some information regarding the work on traits/interfaces and static typing, please?

Cool! Is this built on genie and stipple? Will they remind free and mit licensed?

How will integration with python work ?

Can you please open up an issue on Jet.jl? Even if you can't provide a MWE, it would be helpful to share these experiences

Hi, cool paper! semi related questions:

What do you think of JET.jl?

Tension between Method ambiguities and desire for traits or multiple inheritance is something discussed in the community. Has your group given any thought to this?

Thanks !

Hey! we're tracking JET.jl and think that it's great already and may become even better. We hope to base some of our future stuf off it. Some of us (not me) actually work on a trait design. Multiple inheritance -- not so much: we think it would preclude some important optimizations and that way defeat the whole purpose of Julia (performance + dynamism).

Cool! Looking forward to seeing some of the trait work

Yes, but that's only required for one of those packages.

One of Julia's benefits is that the compiler is hackable so high level abstractions can be experimented with in user space.

There's work being done to solve this in Julia. See escapeanalysis.jl and the immutable array pr in base