This is a neat trick and clever technical work, but is it useful in practical terms?
Like, wouldn't you just download the binary that's been compiled specifically for the platform and architecture that you're using? Rather than relying on a potentially quite fragile method of cross-platform execution.
In a way it kind of reminds me of Urbit. Very clever, very cool, but also very niche and more of a hobbyist showcase project than anything else. Not that there's anything wrong with that of course.
For the consumer it's a simple switch(arch) statement to download the right binary.
But for the developer, it means setting up 9 different build pipelines and artifacts (and realistically, most won't bother with BSD builds and a lot still don't bother with arm64 builds).
It's not necessarily a huge hurdle or an unbearable expense with modern CI services, but it's still a massive deal that this project can make it all unnecessary for every single C/C++ developer out there. If this were a paid product, literally millions of companies would be happy to pay a small fee to save on CI costs, time and maintenance.
Does this really change if Cosmopolitan e.g. outputs 9 different artifacts instead of 1 artifact merging all 9? The advantage you're describing seems to lie mostly in "a C/C++ build system which can actually cross compile without pulling your hair out" not "a C/C++ build system which produces a binary I can take from BSD to Windows and execute unmodified".
It's because the former is much easier/better if you don't also do the latter. The harder thing gives you the easier thing as a side effect, yes, but you could just do the easier thing directly and not do the harder thing at all. Zig's "zig cc" command is an example of a system that gives you the former without doing the latter. If you ONLY care about simplifying your CI for cross-compilation builds, take a look at Zig as your C/C++ compiler frontend.
Write once, run anywhere has been a slogan for coming up on thirty years. Except all implementations of it have acceded to reality in one or more important aspects, such as needing to install Java separately. And it's not just platform-specific compilation, it's everything that could support platform-specific compilation (if you've never tried to cross-compile from Linux to MSVC, you should), and also all sorts of platform-specific code (like console functions vs terminal sequences, or even stuff as banal as $HOME vs $USERPROFILE). Cosmopolitan still isn't perfect, because it doesn't emulate all of Linux, so you still need kernel32.dll here and there. But it is still the best of any attempts.
I agree. You sound like you're speaking from experience. If so, I'd love to hear what sort of stuff you're building with Cosmo, if you're able to share! Feel free to reach out anytime (privately or discord) and let me know what the project can be doing to better serve your needs.
It’s a very cool toy and fun personal project, but it’s not much more even though the author really wants it to be. Your code has to be vaguely portable anyway for this to work. So why would you pay the tradeoffs for a binary that runs in multiple operating systems, which is not that useful.
I noticed a similar comment from you in the same thread. If you don't write portable software, it doesn't mean the world isn't writing portable software in C, C++, Rust, etc. To list a very few ones:
Blender, GIMP, Emacs, Vim, Pidgin, Evince, Firefox, gEdit, Inkscape, Krita, FFmpeg, Python, Perl, ... I could go on and on.
> You can write portable software… and then compile it for each platform to get the best performance and functionality.
Perhaps not what you intended, but I believe this is that exactly what Cosmopolitan is doing:
- They are writing portable software in that it can run on various architectures and operating systems
- They compile it for each platform, even if the output is a single binary
- For the best performance and functionality, they mention several examples of how Cosmopolitan outperforms the native alternatives
I'm sure there are plenty of rebuttals ("Emacs on Windows is a port", "Cygwin isn't portable", "they could make the native version of $WHATEVER more performant", "Cosmopolitan isn't always faster", etc.), all of which are well and good, but would be missing the bigger picture, which is that there are reasons for both approaches (among others!) to exist, an idea that far transcends software.
Like, wouldn't you just download the binary that's been compiled specifically for the platform and architecture that you're using? Rather than relying on a potentially quite fragile method of cross-platform execution.
In a way it kind of reminds me of Urbit. Very clever, very cool, but also very niche and more of a hobbyist showcase project than anything else. Not that there's anything wrong with that of course.