Hi @kip!

My understanding so far is that we can describe Mojo as a system-level language (like Rust, Zig, C++) with Python-like syntax and a Rust-like type system, with a Python runtime embedded within itself. The approaches are somewhat different to Nx (which in itself is closer to Python’s JAX).

One of the interesting things about Mojo is that it is also described as a front-end (aka syntax) to MLIR and you can specify MLIR types and instructions directly in Mojo and their goal is to build the entirety of Python from this (including the Object system). Although note they say Mojo is a superset of Python but it definitely isn’t one right now - e.g. you can’t define classes - and I think it will be very very very hard to keep full Python compatibility, especially if you include the C API.

In other words, Nx is about embedding low-level bits inside a high-level language, and Mojo is about a low-level language with a high-level runtime inside. I know @jackalcooper is working on MLIR integration but I believe his work so far is more akin to embedding low-level bits inside Elixir.

EDIT: it is also interesting that Mojo is borrowed by default - which brings its semantics closer to a functional programming language and mutation needs to be explicitly enabled. More info: https://docs.modular.com/mojo/programming-manual.html#argument-passing-control-and-memory-ownership

new mojo-like DSL in Elixir: GitHub - beaver-lodge/charms: NIF, in Elixir, for Elixir · GitHub
example: charms/bench/enif_quick_sort.ex at main · beaver-lodge/charms · GitHub

I totally agree with reasoning behind this, if we had in erlang/elixir a subset of commands that could compile to native code, it would be much easier to work with the native interface, no need for a secondary language, tool-chain and other nasty things that always blow up when you try to build the project.