Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

I think that’s a good observation. Babel is probably a perfect place to start.

Two things: (1) In Go you can trivially distribute pre built binaries for <num arch> * <num os> targets. Just building with GOOS set to windows, darwin, and linux (with GOARCH set to amd64 and arm64) would cover 99% of all users. (2) Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking. So maybe even the need for a C/C++ toolchain could be avoided.



You're right about cross-compilation, but

> Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking.

...is just wrong. Even when performance doesn't matter at all (and it matters significantly: replacing even a low constant number dynamic library calls with optimized host-local RPCs using a fast transport can be enough to transition latency from "unnoticeable" to "a human can feel the lag"), the complexity undertaken when orchestrating any sort of RPC or webservice/webhook is substantial--absent LD_LIBRARY_PATH hacks and getting libraries installed, you don't have to think about any of that stuff when (dynamically or statically) linking.


I didn't know that about Go, that's pretty cool! I assumed it was like Rust, where the compiler/toolchain makes builds on arbitrary specific platforms really easy to do, but where you still have to actually do those very narrow builds.


I think you may have misunderstood: each “go build” incantation lets you produce a single OS/arch binary, not a “fat binary”. So you make a build per OS/arch pair and distribute it.


> I assumed it was like Rust, where the compiler/toolchain makes builds on arbitrary specific platforms really easy to do, but where you still have to actually do those very narrow builds.

What's the difference?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: