5 ms·

Is compiling once and running on 6 platforms really that compelling? One of Rust’s super powers is that it’s really easy to write code once that can be compiled

Is compiling once and running on 6 platforms really that compelling? One of Rust’s super powers is that it’s really easy to write code once that can be compiled N times for N platforms without making any changes. I’m all about writing code once. But compiling a few times doesn’t seem like that big of a deal to me? The article says it runs on “six operating systems” but I can’t find them listed?

petesergeant 4y ago
> Cosmopolitan Libc ... that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS So some subset of those
pritambarhate 4y ago
The python article mentions those: https://ahgamut.github.io/2021/07/13/ape-python/ https://ahgamut.github.io/2021/07/13/ape-python/ > This post describes a proof-of-concept Python executable (2.7.18 and 3.6.14) built on Cosmopolitan Libc, which allows it to run on six different operating systems (Linux, Mac, Windows, NetBSD, FreeBSD, OpenBSD)
deleted 4y ago
[deleted]
AgentME 4y ago
I'm not sure if the "actually portable executable" stuff is really practical for anything in its current state, but I find it neat the way the development of the project encourages people to try to find unifying abstractions between software environments and practice writing build tools for new software environments.
- nindalf 4y ago
  10 years ago when almost all computers except smartphones were x86 this would have been a gamechanger. Nowadays, we need to account for ARM no matter what. Either the developer machine or the deployment target could be ARM. Therefore the build system needs to be aware of cross compiling.
  - AgentME 4y ago
    I'm not a big fan of how actually portable executable doubles down on x86-64. I think anyone really wanting to make run-anywhere executables that don't bind us to specific CPU architectures should consider something WASM based, like WASI on Wasmtime.
    - int_19h 4y ago
      That requires a wasm runtime to be preinstalled everywhere. The beauty of APE is that it's just a valid executable file on all supported platforms - it doesn't have any dependencies or requirements.
      - the_duke 4y ago
        Hopefully wasm will take off and a high quality wasm runtime (with JIT) will be pre-installed on every system, but we'll see if that happens.
        wongarsu 4y ago
        The Java Runtime is pretty ubiquitous, so maybe compiling to Java bytecode would be a better approach for a "universal" executable, if runtimes are allowed.
        jart 4y ago
        Just be sure to uninstall the browser toolbar Oracle bundled.
        kaba0 4y ago
        Sun* And it has not been the case for close to a decade now.
        int_19h 4y ago
        I haven't seen a PC with JRE installed in many years now.
FullyFunctional 4y ago
I too couldn’t find the magix six but furthermore, the portability dimension I’m most excited about is the transposed one: microprocessor architectures. I daily compile the swap between x64/arm64/rv64 without a hitch and know that there are other options too, but it always Unix (90% Linux). It would have been nice if the OP had spent a few words on the motivation here.
ahgamut 4y ago
Good catch! I updated the post to mention the six operating systems (Linux, Windows, MacOS, FreeBSD, NetBSD, OpenBSD).
fulafel 4y ago
Go users seem to value a single static executable quite highly, a single portable executable would be even better in the same direction.
- pjmlp 4y ago
  Mostly because many of them weren't around when building static executables was the only thing our compilers could spit out.
  - zaphar 4y ago
    As a Go user who values statically linked executables I can definitely say I was around when this was the only thing our compilers could spit out. The reason I value it is because it makes deployment so much easier. I've re-lived DLL Hell so many times on so many systems by now that I'll happily take the memory/filesystem/pactching pain to have something I can deploy and know it will run on the system I deploy it to any day of the week.
    - pjmlp 4y ago
      There is a big difference between valuing it, and acting as if it was a wonder that Go brought into the world never achieved before. Which is how most in the community act like. There is also a lesson on why dynamic linking is used, and why in its absence one needs to resort to IPC.
- trasz 4y ago
  The way go uses system API is completely unportable - and largely unsupported.
- FpUser 4y ago
  Not just Go users. Nearly all products be it desktop GUI applications that self-update or backend servers I've ever developed are like this. Saves me a lot on deployments.
- cyphar 4y ago
  It should be noted Go hasn't spit out static executables by default for at least 5 years now (if not longer), and if you want static executables from Go it requires several arcane incantations (not unlike getting a static binary from GCC). Basically every Go executable is dynamically linked against libc these days unless the builder goes seriously out of their way to get a static binary.

petesergeant 4y ago

> Cosmopolitan Libc ... that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS So some subset of those

pritambarhate 4y ago

The python article mentions those: https://ahgamut.github.io/2021/07/13/ape-python/ https://ahgamut.github.io/2021/07/13/ape-python/ > This post describes a proof-of-concept Python executable (2.7.18 and 3.6.14) built on Cosmopolitan Libc, which allows it to run on six different operating systems (Linux, Mac, Windows, NetBSD, FreeBSD, OpenBSD)

deleted 4y ago

[deleted]

AgentME 4y ago

I'm not sure if the "actually portable executable" stuff is really practical for anything in its current state, but I find it neat the way the development of the project encourages people to try to find unifying abstractions between software environments and practice writing build tools for new software environments.

nindalf 4y ago
10 years ago when almost all computers except smartphones were x86 this would have been a gamechanger. Nowadays, we need to account for ARM no matter what. Either the developer machine or the deployment target could be ARM. Therefore the build system needs to be aware of cross compiling.
- AgentME 4y ago
  I'm not a big fan of how actually portable executable doubles down on x86-64. I think anyone really wanting to make run-anywhere executables that don't bind us to specific CPU architectures should consider something WASM based, like WASI on Wasmtime.
  - int_19h 4y ago
    That requires a wasm runtime to be preinstalled everywhere. The beauty of APE is that it's just a valid executable file on all supported platforms - it doesn't have any dependencies or requirements.
    - the_duke 4y ago
      Hopefully wasm will take off and a high quality wasm runtime (with JIT) will be pre-installed on every system, but we'll see if that happens.
      - wongarsu 4y ago
        The Java Runtime is pretty ubiquitous, so maybe compiling to Java bytecode would be a better approach for a "universal" executable, if runtimes are allowed.
        jart 4y ago
        Just be sure to uninstall the browser toolbar Oracle bundled.
        kaba0 4y ago
        Sun* And it has not been the case for close to a decade now.
        int_19h 4y ago
        I haven't seen a PC with JRE installed in many years now.

FullyFunctional 4y ago

I too couldn’t find the magix six but furthermore, the portability dimension I’m most excited about is the transposed one: microprocessor architectures. I daily compile the swap between x64/arm64/rv64 without a hitch and know that there are other options too, but it always Unix (90% Linux). It would have been nice if the OP had spent a few words on the motivation here.

ahgamut 4y ago

Good catch! I updated the post to mention the six operating systems (Linux, Windows, MacOS, FreeBSD, NetBSD, OpenBSD).

fulafel 4y ago

Go users seem to value a single static executable quite highly, a single portable executable would be even better in the same direction.

pjmlp 4y ago
Mostly because many of them weren't around when building static executables was the only thing our compilers could spit out.
- zaphar 4y ago
  As a Go user who values statically linked executables I can definitely say I was around when this was the only thing our compilers could spit out. The reason I value it is because it makes deployment so much easier. I've re-lived DLL Hell so many times on so many systems by now that I'll happily take the memory/filesystem/pactching pain to have something I can deploy and know it will run on the system I deploy it to any day of the week.
  - pjmlp 4y ago
    There is a big difference between valuing it, and acting as if it was a wonder that Go brought into the world never achieved before. Which is how most in the community act like. There is also a lesson on why dynamic linking is used, and why in its absence one needs to resort to IPC.
trasz 4y ago
The way go uses system API is completely unportable - and largely unsupported.
FpUser 4y ago
Not just Go users. Nearly all products be it desktop GUI applications that self-update or backend servers I've ever developed are like this. Saves me a lot on deployments.
cyphar 4y ago
It should be noted Go hasn't spit out static executables by default for at least 5 years now (if not longer), and if you want static executables from Go it requires several arcane incantations (not unlike getting a static binary from GCC). Basically every Go executable is dynamically linked against libc these days unless the builder goes seriously out of their way to get a static binary.