NuMojo v0.9.0 is here!

Community Showcase
1

NuMojo v0.9.0 is finally here!

It took a while :). This release is a solid step forward in correctness, execution consistency, and future accelerator support and also part of our push toward more consistent stable releases alongside Mojo itself.

Check out the changelog for full details.

:locked_with_key: Safer Views & Memory Semantics

We’ve reworked view handling to make NDArray safer and more predictable:

  • Strict contiguity checks (is_c_contiguous, is_f_contiguous, etc.)
  • contiguous() now guarantees an owned C-contiguous copy
  • New NDArray.offset enables safe shared-buffer views without pointer shifting
  • Clearer semantics: .copy() → views, .deep_copy() → allocations
    (this may evolve further as we push view support across all of NDArray)

Unified Execution with HostExecutor

All core routines now run through the new HostExecutor. This is a step toward unifying SIMD execution, similar in spirit to NumPy ufuncs for host-side operations.

  • SIMD-friendly apply_unary, apply_binary, and apply_ternary and predicate operations.

This provides consistent, optimized execution path across the library.

Device & Accelerator Foundations

We’re starting to lay the groundwork for GPU/accelerator support.

  • New Device abstraction (CPU/GPU, API similar to torch.device)
  • Split storage model: HostStorage vs DeviceStorage
  • Unified container system for future device-agnostic arrays

This sets the stage for upcoming GPU support in NDArray. Expect some fun things in the next release!

Zero-Copy Interop via DLPack

Zero-copy interop is finally here via DLPack, currently tested with NumPy and PyTorch.

  • Added DLPack support for seamless interoperability
  • Zero-copy exchange with NumPy and other frameworks
  • Benchmarks included to track performance regressions

:hammer_and_wrench: Fixes & Improvements

  • Better organized docs with user & developer guides and more examples!
  • Corrected complex indexing behavior in __getitem__
  • Fixed memory leaks and device handling issues
  • Updated for latest Mojo syntax and compatibility changes
  • Expanded test coverage across indexing, views, logic ops, and more

Huge thanks to all contributors who helped push this release forward.

Four mojicians :magic_wand: (shivasankarka, forfudan, josiahls, birgerbr) contributed to this release.

Give it a try and let us know how we can improve!

7 Likes
2

Horray :partying_face:

1 Like
3

Great work! I have a question about NDarray, will that go away in the future with tensor related api? Or am I confusing NDBuffer snd NDArray? I’m just wondering if I should wait a little longer to start including numojo in my repo.

Thanks for all your work!

4

Thanks for your questions. NuMojo focuses on NumPy-style n-dimensional arrays. It is not a tensor/autograd framework and has no plans to become one.

5

Gotcha, that is exactly what I’m looking for. I was referring to my probably poor understanding of some mojo array primitives. I do want to just multiply some mutidimensional arrays around and have used numojo in the past and enjoyed it.

I had thought that mojo itself was going to deprecate some of the old ways of handling multidimensional arrays and wanted to make sure I didn’t adopt something that would be transitioning in a little bit. But if you are saying that NDArray looks here to stay then I’ll start folding it into my repo.

In my mind tensor =multidimensional array,

Again, thank you for all your work, really cool and powerful stuff.

1 Like
6

Thank you :smiley:

Mojo used to have a Tensor struct which was deprecated in v25.4. Now there is another LayoutTensor struct whose shape is compile-time known. The numojo.NDArray is a runtime-dynamic array (like NumPy’s ndarray ). Shape, strides, and dtype are determined at runtime.

I am very sure that the API of the current numojo.NDArray would be stable and is safe to use it. In fact, we are also preparing to use it as the data container for other libraries.

2 Likes
7

Great! Now I can replace my junky temporary arrays.

1 Like