Hacker News Reader

Comment by forrestthewoods | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

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.

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.

Just be sure to uninstall the browser toolbar Oracle bundled.

Sun*

And it has not been the case for close to a decade now.

I haven't seen a PC with JRE installed in many years now.

Agreed, though I guess it's that I'm not too interested in the general use-case of generic independent executables that can run on any system by themselves, which APE is aimed at. It's probably good for me to be explicit that I'm interested in a more specific use-case that I think is shared by some people interested in very portable executables: where you have some application that contains redistributable plugins, and those plugins must be executable by the application on any OS/architecture that the application runs on and be sandboxable. WASM is very well-shaped for this specific use-case; it might be okay for the general independent-executable use-case if you embed a few small WASM interpreters or if your target platforms each include one (which seems increasingly reasonable on modern systems that have one because it's needed for the system webviews).

ARM isn't just a single architecture either, there's ARMv6, ARMv7, ARMv8/ARM64, etc. Most of the platforms folks are using are ARM64 but not all of them!

The sooner we ditch ARMv7 and predecessors, the better.

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

Mostly because many of them weren't around when building static executables was the only thing our compilers could spit out.

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.

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.

The way go uses system API is completely unportable - and largely unsupported.

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.

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.

I'm not sure that's true.

    $ go version
    go version go1.18.3 linux/amd64
    
    $ cat static.go 
    package main
    
    import "fmt"
    
    func main() {
     fmt.Println("static")
    }
    
    $ go build static.go 
    
    $ file static
    static: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=TSoFKMWZzy5G6qyFvxx5/dwEbvdQns9f-iffR-lbW/iTmqy3UF8tbT-GGwVH61/lUZUt7_XebTifpVvE_52, not stripped
    
    $ ldd static
     not a dynamic executable

But it might not be the case for all systems. And some things, like using CGO or performing DNS lookups, will necessitate dynamic linking.

The python article mentions those: 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)

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.

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

> Cosmopolitan Libc ... that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS

So some subset of those

Reply on news.ycombinator.com