4 ms·

> Part of Go's popularity is due to how easy it is to produce self-contained executables. Rust too... :D

winrid 3y ago
Nah, rust still depends on libc at runtime which is a pain. Go doesn't have this problem afaik as it has its own stdlib and runtime.
- arp242 3y ago
  You can statically link libc in Rust too; at least, if teh interwebz is correct (not a Rust expert); you just need some extra flags. This is actually not that different from Go in practice; many Go binaries are linked to libc: it happens as soon as you or a dependency imports the very commonly used "net" package unless you specifically set CGO_ENABLED=0, -tags=netgo, or use -extldflags=-static.
  - Conscat 3y ago
    Statically linking libC is problematic in various ways. I really appreciate that Zig has its own runtime that is designed specifically for this use case.
    - Kamq 3y ago
      > Statically linking libC is problematic in various ways. Are we just talking about standard rop gadget vulnerabilities, or is there something else that's a problem with it?
      - thristian 3y ago
        glibc, Linux's traditional libc, can dynamically load hostname resolution policies, but that only works if the executable has access to dynamic loading, i.e. if it's not a static executable. Dynamically loading hostname resolution policies doesn't happen often, but when it does happen it's a right pain to diagnose why some tools see the right hostname and other tools don't.
  - maeln 3y ago
    You can, but usually, if you really want a binary with no runtime dependencies, most people will just compile their code against musl libc instead. The only issue is that some lib sometime do not compile (or at least without some workaround) with musl. Although it often concern one specific platform (looking at you Mac OS).
- mirashii 3y ago
  > Nah, rust still depends on libc at runtime which is a pain. It does in general, though I don't really think this is a big pain or blocker in the general case, there are very version requirements around libc. > Go doesn't have this problem afaik as it has its own stdlib and runtime. That's also true, but it's not really a pure win. Choosing not to use a battletested libc has led to a variety of subtle and difficult to diagnose bugs over the years, e.g. https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
  - jrockway 3y ago
    I think it's a pure win. Writing your program in 1 language instead of 2 is worth one simple misunderstanding of vDSO.
  - Patrickmi 3y ago
    This is obviously a trade off, it’s not a bug there’re certain things one must overcome “with time”, even if Go starts using libc am pretty sure the Go team will have their own libc which makes no difference unless it deals with the problem Cgo have
- d0100 3y ago
  Indeed, I built Supabase's edge-runtime and sent the binary to another pc with a earlier Ubuntu version only to discover it wont work I went on a wild goose chase to build static Rust but deno can't target musl yet and the issue is a few years old
- leeoniya 3y ago
  https://github.com/redox-os/relibc https://github.com/redox-os/relibc ? https://musl.libc.org/ https://musl.libc.org/
- saagarjha 3y ago
  Not always, because some platforms require you to use their libc.
diego_sandoval 3y ago
What bothers me is that even when that capability exists, most of the Rust open source programs that I've tried don't distribute binaries, and still ask you to install cargo and compile the program from source.
- deleted 3y ago
  [deleted]
- VWWHFSfQ 3y ago
  My experience is the opposite. Nearly every Rust tool I've used offers static binaries for various platforms.

Nah, rust still depends on libc at runtime which is a pain. Go doesn't have this problem afaik as it has its own stdlib and runtime.

arp242 3y ago
You can statically link libc in Rust too; at least, if teh interwebz is correct (not a Rust expert); you just need some extra flags. This is actually not that different from Go in practice; many Go binaries are linked to libc: it happens as soon as you or a dependency imports the very commonly used "net" package unless you specifically set CGO_ENABLED=0, -tags=netgo, or use -extldflags=-static.
- Conscat 3y ago
  Statically linking libC is problematic in various ways. I really appreciate that Zig has its own runtime that is designed specifically for this use case.
  - Kamq 3y ago
    > Statically linking libC is problematic in various ways. Are we just talking about standard rop gadget vulnerabilities, or is there something else that's a problem with it?
    - thristian 3y ago
      glibc, Linux's traditional libc, can dynamically load hostname resolution policies, but that only works if the executable has access to dynamic loading, i.e. if it's not a static executable. Dynamically loading hostname resolution policies doesn't happen often, but when it does happen it's a right pain to diagnose why some tools see the right hostname and other tools don't.
- maeln 3y ago
  You can, but usually, if you really want a binary with no runtime dependencies, most people will just compile their code against musl libc instead. The only issue is that some lib sometime do not compile (or at least without some workaround) with musl. Although it often concern one specific platform (looking at you Mac OS).
mirashii 3y ago
> Nah, rust still depends on libc at runtime which is a pain. It does in general, though I don't really think this is a big pain or blocker in the general case, there are very version requirements around libc. > Go doesn't have this problem afaik as it has its own stdlib and runtime. That's also true, but it's not really a pure win. Choosing not to use a battletested libc has led to a variety of subtle and difficult to diagnose bugs over the years, e.g. https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
- jrockway 3y ago
  I think it's a pure win. Writing your program in 1 language instead of 2 is worth one simple misunderstanding of vDSO.
- Patrickmi 3y ago
  This is obviously a trade off, it’s not a bug there’re certain things one must overcome “with time”, even if Go starts using libc am pretty sure the Go team will have their own libc which makes no difference unless it deals with the problem Cgo have
d0100 3y ago
Indeed, I built Supabase's edge-runtime and sent the binary to another pc with a earlier Ubuntu version only to discover it wont work I went on a wild goose chase to build static Rust but deno can't target musl yet and the issue is a few years old
leeoniya 3y ago
https://github.com/redox-os/relibc https://github.com/redox-os/relibc ? https://musl.libc.org/ https://musl.libc.org/
saagarjha 3y ago
Not always, because some platforms require you to use their libc.

diego_sandoval 3y ago

What bothers me is that even when that capability exists, most of the Rust open source programs that I've tried don't distribute binaries, and still ask you to install cargo and compile the program from source.

deleted 3y ago
[deleted]
VWWHFSfQ 3y ago
My experience is the opposite. Nearly every Rust tool I've used offers static binaries for various platforms.