Logo

This Week in Mojo 2023-06-30

Official

Community

Playground Update

Full changelog hereopen in new window

⭐️ New

You can now share .ipynb notebook files in Mojo Playground. Just save a file in the shared directory, and then right-click the file and select Copy Sharable link. To open a shared notebook, you must already have access to Mojo Playground. When you open a shared notebook, click Import at the top of the notebook to save your own copy. For more details about this feature, see the instructions inside the Mojo Playground file browser help directory.

🦋 Changed

The unroll2() and unroll3() functions in the Functional module have been renamed to overload the unroll() function. These functions unroll 2D and 3D loops and unroll() can determine the intent based on the number of input parameters.

🛠️ Fixed

Mojo Team Answers

URL based imports

Traditionally, it has been a responsibility placed on the build system, but that makes reproducible scripts harder to manage. Having first-class support for URL imports seem like the right direction for Mojo. We're still focusing on nailing down having packages first, but later on thinking about distribution and sharing will be important to building an ecosystem.

Pointers

Pointers serve an important function even for safe code, it allows type-erasing a reference into an arbitrary container that holds a value in memory, just like a safe reference does. This is a pretty important thing, but you really want this to be safe for the common use-case. Such a thing would not support pointer arithmetic or indexing though, this is something a Slice type would support.

Energy Efficiency

We have not done any analysis about energy efficiency, my guess is that Mojo would be in the top 2 or 3, since Mojo does not do anything fancy behind your back. We do need to study this however.

Macros

I think it is important to have some sort of macro-like feature for syntax - one specific use-case for this is to enable things like "parallel_for" to be library features instead of language features. That said, we aren't looking to implement language features for their own sake, we should be motivated by specific problems we want to solve.

Multiple Dispatch

This is a nice feature from (eg) Julia, but it depends entirely on its compilation model which doesn't work the same way as Mojo's.

Python Type Hints

Mojo can tell the difference between Python "hints" and Mojo types. There will be no problem here, we can support the hints for compatibility (by ignoring them) just like Python does.

Rust

I don't think that mojo has any burden to prove novelty vs rust. We're happy to adopt good ideas from Rust as with all other existing languages. Graydon himself was very happy for Rust to pull good ideas when he started it, and wasn't ashamed to admit it. Mojo is similar.

I also don't see Rust and Mojo in competition, while I'm hoping that Mojo can learn from and improve vs Rust in various areas, they're clearly servicing different segments of the world. Yes there is some crossover, but Rust is far more mature than Mojo and Rust is continuously improving as well. If you'd like to continue using Rust, go for it 😀.

If you're interested in language nerdery, then yes, there are ways in which Mojo can provide better performance than Rust. There are two categories:

  1. There are very low level implementation details (e.g. borrow by default instead of move, moves not implying memcpy etc) that can affect idiomatic use of the language at scale. As others say, it will be difficult to know how these work out until Mojo is more complete and there are more at-scale applications like your caching system. Mojo's trait system in particular is missing, and it's hard to write much realistic generic code without that!

  2. Mojo open new frontiers for GPUs and other accelerators. We can all have different opinions about what the "end of moore's" law means for computing, but if computers keep getting weirder, and if that matters for important workloads that you care about, then Mojo will be interesting because it can talk to them in ways that other languages weren't really built for.

That said if you care about Fibonacci on X86 cpus, both Rust and Mojo (and Clang and many many others) are all zero cost languages that boil down to LLVM. As such, any advantage claimed on such a workload will be more about accidental implementation details than anything else and could be easily fixed.