| Thanks, but I still can't tell from your response what problem Cosmopolitan is trying to solve. I came across some of the following statements in your website (https://justine.lol/cosmopolitan/index.html): > "Cosmopolitan makes C a build-once run-anywhere language, similar to Java, except it doesn't require interpreters or virtual machines be installed beforehand" Glancing at the code so-far, Cosmopolitan is really just an alternative libc implementation. It's important we acknowledge that there's only so much you can do with a libc implementation: it's a paper-thin abstraction layer for a small subset of rudimentary APIs. It's common for software today to depend on operating system interfaces (which are platform-specific), either directly (via static/dynamic linking with operating system libraries) or indirectly (delegating to a runtime environment such as Java, Python, .NET Core, Mono, Wine, and others). I don't see how Cosmopolitan caters for these scenarios, and I don't see why you would make that comparison in the first place. > "Cosmo provides the same portability benefits as high-level languages like Go and Rust, but it doesn't invent a new language and you won't need to configure a CI system to build separate binaries for each operating system" Cosmopolitan doesn't change anything about the C language itself, right? How portable a certain C project is depends entirely on the business logic within the code. Any C code using nothing but libc is pretty much guaranteed to be "portable" (it can be built using almost any combination of hardware, operating systems and compilers) - I'm not sure what Cosmopolitan contributes to the portability story? > "What Cosmopolitan focuses on is fixing C by decoupling it from platforms" C is already "decoupled from platforms", so I'm confused by this statement. There are a lot of projects out there that don't use libc at-all, or use their own custom abstractions on-top of platform-specific code (#ifdefs, fancy buildsystems, etc). There's nothing about Cosmopolitan itself that makes it somehow "decoupled from platforms": the decoupling happens by virtue of writing code that relies on the public interfaces exposed by libc, and the ability to swap libc at both compile- and runtimes. |
Packaging multiple entry points in the same file is a clever hack but is extremely brittle (for example, archiving/re-archiving can mangle relevant sections which ZIP doesn't care about -- this will break your binary), ELF uses a pre-processing step which renders the binary non-portable once it's run, and the cross-platform libc stuff has been done since time eternal.
Not to mention that, as you say, just C is nigh useless these days, anyway. It's kind of funny to see people comparing this to Electron.