Shared Object Support?
I doubt this is the case, but is there by chance a way to compile mojo to linux shared objects? If not is there any plan to include the ability in the future? Even if they cant cross operate with other executables coded in languages other than mojo, they'd be super useful for a project I have in mind.
8 Replies
Shared objects cause a lot of issues for languages with generics. C++ has made a lot of language-level sacrifices to support them. Right now Mojo does not have a stable ABI, which means shared objects would need to expose a C ABI, which removes most of the good features of Mojo.
I ran into this issue with Rust and found that using shared memory IPC or unix sockets and having one program per language was sufficient for almost all cases.
If you want a plugin system, the way this is typically done is to round-trip via the C ABI. Mojo will eventually get clean interop with C/C++, and I think Rust interop may be doable.
Ah damn. My project in mind was to reimplement Erlang's BEAM engine in MOJO but in native compiled MOJO rather than on a VM. The shared objects idea was to make hot swap-ability of code viable. Back to the drawing board to figure out something else then XD. Thanks @Owen Hilyard
Congrats @Jabadahut50, you just advanced to level 2!
Shared memory IPC could work but that'd be a LOT of individual processes. I feel like it'd eat a lot of RAM. May just have to wait for some updates or something if I can't figure out a different way to do it.
@Owen Hilyard follow up question... is there per chance a way to compile mojo to MLIR bytecode? The bytecode format is fairly well documented and I know MOJO gets compiled down to MLIR before machine language anyway... and while i'd prefer compiled machine code, creating a bytecode interpreter could be another way of getting the functionality I want without too much performance sacrifice?
I don't think the current compiler allows that. Mojo has a JIT mode (used in the REPL and notebooks), so you may be able to use that once it comes out, it should still be faster than BEAM.
That could work... guess I'll be waiting for that then. Appreciate it.
By the way, if you are doing that wait until I finish writing async IO to implement IO. The interface is going to look a little weird but should give you some options that are better than what production BEAM does right now for message passing.
oooh now i'm even more impatiantley waiting XD