Modverse Weekly - Issue 22

February 15, 2024

Jack Clayton

AI Developer Advocate

Laszlo Kindrat

AI Compiler Engineer

Mojo has been getting discussed across social media over the past week. We published a community blog titled Outperforming Rust ⚙️ DNA sequence parsing benchmarks by 50% with Mojo 🔥. This caught @ThePrimagen's attention, and he did a reaction video on the weekend. It generated a lot of interest, and sparked some interesting community discussion. We released a follow-up blog on Monday: Mojo vs. Rust: is Mojo 🔥 faster than Rust 🦀, to highlight some areas where Mojo does have the potential to outperform Rust. It was great to see the hot takes about Mojo's place in the AI ecosystem. Here's one from a respected Rustacean and Zero to Production in Rust author:

Great to see that Mojo's value proposition is coming across to the wider community! Mojo is purpose built to simplify the AI ecosystem in a way that no other language is attempting, while learning from all the great things that modern languages like Rust do: 🔥 ❤️ 🦀.

Blogs, Tutorials, and Videos

Awesome Mojo

  • Kirill released a plugin for JetBrains editors like PyCharm to support Mojo

Mojo Language Committee

These are the results from the second meeting to discuss prioritization of feature requests from the community, thanks for all the great suggestions, and to Laszlo for driving this forward and summarizing the results.

#1649: Supporting trailing comma for Python compatibility: Accepted

We discussed the problem of trailing commas in unpacking as well as in function call expressions like foo(a, b,), which is supported in Python. We decided that this is something we want to support; perhaps it looks quirky, but it is part of Python, and syntactic compatibility with Python is an important goal of Mojo. We acknowledge that in some cases syntactic compatibility might be at odds with building a better Python, but we think this particular feature poses no such risks. This means, that we will treat this as a missing feature, and will work towards fixing it.

#1705: Give overload precedence to user-defined __init__ in @value structs: Mitigating underlying issues

The team discussed the issues that arise when explicit overloads of __init__ exist on a @value struct, and acknowledge that this area could use some quality of life improvement. Our goal with the @value decorator is to provide a simple and predictable model for generating magic methods for structs with value-like semantics, leading to better readability and less boilerplate. We think that modifying overload resolution rules to treat methods synthesized by @value differently would make the model more complicated. Instead, we will allow customization of @value and what methods it synthesizes, so that one can opt in/out of generating some of them. We will also consider implementing some basic checks in the parser that could catch and warn about common ambiguities related to synthesized constructors. We will start to flesh out the details of this soon.

#1731: Add is_compile_time_constant magic method: Postponed

We deliberated over implementing a magic method like is_compile_time_constant as suggested in the ticket. We concluded there is no way to know if an argument will be passed a dynamic or compile time value, so per function compilation cannot reason about this. There are sensible, but verbose alternatives to achieve similar functionality as seen in the ticket comments, which are used commonly by Mojicians 🪄. In the future, we might consider adding some syntactic sugar for declaring arguments that function authors would like to compile-time specialize on, but for now, we would like to focus on building out the core functionality of the language.