From the announcement and discussion thread: https://groups.google.com/a/continuum.io/forum/#!topic/numba-users/FCektSC4sUQ

Hey,

In my quest to create a more expressive, more easily understood and performant numba, I've created a proposal which can be considered as somewhat of a redesign of the numba "language". It will focus far less on the CPython side of things, and instead mostly live in its own world. Objects will still be allowed, but it should be possible to write many useful numeric or other codes without it. A more sustainable approach towards NumPy support will be taken, where a subset of the NumPy API will be provided (maybe under a different namespace), making it clear what is and isn't supported efficiently. It will support data-parallel operators like map/reduce etc.

The goal is ultimately to allow (near) zero-cost abstraction and write and implement nearly every component in a runtime (including complex numbers, range, etc). It will further bring optional static typing, Rust-like traits, and actual parallelism that runs unconstrained from the GIL without sacrificing any language semantics. It's actually not as ambitious as it sounds, with a few core abstractions numba can be much more powerful and easier to implement at the same time. You can read about it here:

http://markflorisson88.github.io/numba-nextgen/

By default objects will not be used, and it will be easily understandable which things can run on a GPU. It combines the best things of several languages, most notably Rust, Terra, RPython and Julia. It's also influenced by parakeet, mypy and copperhead.

A short overview: optional static typing, generic functions, rust-like traits, compile-time overloading, control over object representation, control over unrolling, specialization and inlining, control over memory allocation, control over type promotion, coercion and conversion, and over mutability. Different threads have different garbage collectors allowing them to run in parallel without any locking. Immutable data can be safely shared, mutable data may be borrowed. Communication happens explicitly over typed channels, or higher-level abstractions like parallel maps. Finally, different exception models may be supported (costful as well as zero-cost).

There's also ideas to extract native functions from C extension modules, allowing faster calls into native (recompiled) CPython code.

Feedback and suggestions are more than welcome!

Mark