Timeline for C/C++ Interop, FFI
The Mojo roadmap mentions a future FFI between it and C/C++ [1]. Is there an estimated timeframe when this would become available?
I'm interested in Mojo's potential for robotics and embedded systems. Interop with C or C++ libraries would accelerate the pace at which it could be adopted in this space.
[1]: https://docs.modular.com/mojo/roadmap.html#cc-interop
Modular Docs - Mojo🔥 roadmap & sharp edges
A summary of our Mojo plans, including upcoming features and things we need to fix.
10 Replies
We're not actively working on this, so cannot give a useful estimate. I'd "wild guess" that it will come up in the spring though?
Traits and other things like that are more important to bring up in the near future.
In the mean-time, is it a fine, fine use of our time to prototype large-scale image processing and deep learning pipelines (say medical and satellite images) in a combination of C++ and Halide and then try out the DL pipeline using Mojo? We need to move projects and team know-how forward, but it feels like Mojo is taking the oxygen out of those other projects while still not having anything like feature parity. For a small team, this is a big question with big financial implications. I'd love to see some Lex Fridman love between the Mojo folks and Andrew Adams, et al.
Good to know, thanks for this information Chris.
@mikepettit I see your point--it's difficult to develop in two separate language pipelines without being able to share code between them.
At the same time, Mojo's barely at v0.3 and priorities for its development need to be chosen somehow.
Hey Chris, real interesting to hear the work on traits. Will it be more similar to Rust's traits or Golang's interface? Both are very similar but I am hoping we can have compile time constants embedded in traits (i.e. Rust's traits), this saves a lot of time at defining a constant associated to a set of behaviours. 😁
We don't have a full design for them yet (work is just getting started on traits now) but we will iteratively increase the feature and capability set over time. I expect we'll end up with a novel combination of haskell type classes, rust traits, swift protocols, go interfaces etc. They're all mostly remixes of the haskell typeclass work with frills here and there. We'll aim to be SoTA and fit well with the rest of Mojo, unlocking the important generic programming usecases we need for an "STL" like standard library.
Will this include the ability of mojo to be called from c/c++? Would be awesome to write new features for existing c/c++ high performance applications with the higher usability of mojo
I think it is truly amazing with how you're aiming what Mojo can be.
1. Runtime interoperability with Python interpreter.
2. Compile time evaluation with
@parameter
, @nonmaterializable
and alias
.
3. First class support for interfacing with lower level IR entities like MLIR. And even lower level support for SIMD.
4. Making it memory-safe without putting too much burden on the engineer, without a garbage collector (or at least on the Mojo side, not on the Python interoperability), without a lifetime annotation hassle (actually, a mess 😆) and hopefully without the engineer to remember calling free
, lol.Yeah of course. We want mix-and-match interop with the C/C++ world as well as the python world. Our forthcoming debugger fully supports debugging intermixed C(++) and Mojo frames for example.
Exactly. A small team which is about to start implementing new image-processing pipelines, relying on source images made available by modules written in C++ can now rely on Halide to come up with some sort of abstraction over the hardware. This is where Mojo would excel, but I doubt wrapping the C++ module into a Python plugin and then use CPython inside Mojo to access the C++ generated objects would be anything comparable to a proper C/C++ Interop. A C FFI is what we need to dive deep into the Modular world.
Yeah, it's a strong goal for Mojo to (over time) get us out of "write things in python for hackability, then rewrite in something else for deployment". Lots of folks are suffering, and +1 for models on the edge.