Recently out as 1.0 stable and few days later open sourced:
There are only three ways to tackle these problems. Let’s briefly evaluate the pros and cons of each:
Extend an existing language like C++, Rust, Julia, Swift:
Pro: You get an existing implementation and community.
[true]
Con: None of these languages support the hardware features we need—they were designed for CPUs. They are also all 10+ years old, don’t provide the modern metaprogramming features we need, and weren’t designed to support hardware features required for AI (such as float6).
Yes, designed for CPUs, like most languages, maybe unfair to say only designed for, or at least only useful for.
[Is discourse incredibly slow for anyone else, like typing in (copy/paste was instant), while other sites ok? With Firefox 155 at least. I had strange problems before the update, that got fixed, though possibly extension related, and I now run in safe mode.
Looking into way, likely related (though was seeing before the update then not slowing down):
$ firefox --safe-mode
..
[Parent 614720, IPC I/O Parent] WARNING: process 615129 exited on signal 9: file checkouts/gecko/ipc/chromium/src/chrome/common/process_watcher_posix_sigchld.cc:161
]
I’m genuinly curious to know what “modern metaprogramming feature” they require and claim other languages (incl. Julia) don’t have, and whether Julia could provide them.
It’s not so much that other languages don’t have them, it’s that no particular language has it the way they want. Most languages are created for this reason, and the really particular aspects like Julia’s world age are a relatively small fraction compared to the overlapping features. Mojo is also an AI-first language, so it does implement features in ways that would be odd outside the context of AI-associated hardware, like semantic loop unrolling in comptime for.
Mojo’s sense of metaprogramming seems to be more about guaranteeing compile-time information and computation, not arbitrary expression manipulation. To start a non-exhaustive comparison, we’re familiar with parameters in types and methods. Mojo also distinguishes overloaded functions (like multimethods but only statically dispatched) by Rust-like trait bounds and parameter value constraints that feel like a strictly subsetting version of Erlang’s guards. comptime seems to semantically identify compile-time values like Rust’s const and C++'s constexpr.
Can we have this stuff in Julia? Never say never, but I wouldn’t hold my breath. Julia’s method dispatch must be performant enough to occur at runtime, and it’s unclear if that’s feasible after adding more factors to distinguish methods. Holy traits can help split algorithms across different methods by associating auxiliary input types with type-like characteristics or parameter value constraints, but it’s not as ergonomic and probably not as powerful as distinct language features. Julia does execute simple associations and small functions at compile-time and has @assume_effects and generated functions to nudge the compiler for bigger functions, but there’s no semantic division or guarantee of compile-time computation. The tradeoff is that we’re not strictly constrained by the associated limitations, e.g. no I/O or FFI, until we run into logical or precompilation-caching issues. That’s convenient because a good chunk of compile-time computation could be done by just running something beforehand or in a simple function compiled without constraints, and Julia very much prioritizes convenience. For example, people have been interested in formal interfaces or traits for years, but it’s very unlikely we’ll ever routinely list every trait a method parameter might need for callees.