β² 873 βΌ Linux and Chill (lemmy.world) submitted 2 years ago by Clbull@lemmy.world to c/linuxmemes@lemmy.world 93 comments fedilink hide all child comments
[β] possiblylinux127@lemmy.zip 5 points 2 years ago (1 child) I like Go better However, C is still king in a lot of ways permalink fedilink source parent hideshow 2 child comments replies: [β] m_f@midwest.social 6 points 2 years ago (2 children) C is definitely still king, but I wonder if crABI will eventually be able to dethrone it: https://github.com/rust-lang/rust/issues/111423 If they can define a useful ABI that manages to include lifetimes, that might just be enough of an improvement to get people to switch over from assuming the C ABI everywhere. permalink fedilink source parent hideshow 4 child comments replies: [β] syklemil@discuss.tchncs.de 3 points 2 years ago Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with "I'm tired of paying for an ABI stability I'm not using" it's not so clear it would really be a boon to Rust. That said no_std appears to be what people go to for the lean Rust. And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It's part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it. permalink fedilink source parent [β] possiblylinux127@lemmy.zip 1 point 2 years ago (1 child) The problem is that both Rust and Go are huge. The compiled binaries are bigger and the compilers themselves and slower and more resource intensive. The current benefit to C is that is lean and compiles quickly. permalink fedilink source parent hideshow 2 child comments replies: [β] Zangoose@lemmy.world 5 points 2 years ago* Rust is only huge because it doesn't have an ABI. If you had an ABI (and didn't have to compile every single dependency into the binary) the binary sizes would probably drop a lot to the point where they're only slightly bigger than a C counterpart Edit: I don't know if Go has an ABI but they also include a runtime garbage collector in their binaries so that probably has something to do with it. permalink fedilink source parent
[β] m_f@midwest.social 6 points 2 years ago (2 children) C is definitely still king, but I wonder if crABI will eventually be able to dethrone it: https://github.com/rust-lang/rust/issues/111423 If they can define a useful ABI that manages to include lifetimes, that might just be enough of an improvement to get people to switch over from assuming the C ABI everywhere. permalink fedilink source parent hideshow 4 child comments replies: [β] syklemil@discuss.tchncs.de 3 points 2 years ago Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with "I'm tired of paying for an ABI stability I'm not using" it's not so clear it would really be a boon to Rust. That said no_std appears to be what people go to for the lean Rust. And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It's part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it. permalink fedilink source parent [β] possiblylinux127@lemmy.zip 1 point 2 years ago (1 child) The problem is that both Rust and Go are huge. The compiled binaries are bigger and the compilers themselves and slower and more resource intensive. The current benefit to C is that is lean and compiles quickly. permalink fedilink source parent hideshow 2 child comments replies: [β] Zangoose@lemmy.world 5 points 2 years ago* Rust is only huge because it doesn't have an ABI. If you had an ABI (and didn't have to compile every single dependency into the binary) the binary sizes would probably drop a lot to the point where they're only slightly bigger than a C counterpart Edit: I don't know if Go has an ABI but they also include a runtime garbage collector in their binaries so that probably has something to do with it. permalink fedilink source parent
[β] syklemil@discuss.tchncs.de 3 points 2 years ago Still remains to be seen if a potential rust ABI can avoid becoming a chain to the wall the way the C++ ABI seems to have become. When a lot of C++ers apparently agree with "I'm tired of paying for an ABI stability I'm not using" it's not so clear it would really be a boon to Rust. That said no_std appears to be what people go to for the lean Rust. And a lot of us are happy not having to juggle shared dependencies, but instead having somewhat fat but self-contained binaries. It's part of the draw of Go too; fat binaries come up as a way to avoid managing e.g. Python dependencies across OS-es. With Rust and Go you can build just one binary per architecture/libc and be done with it. permalink fedilink source parent
[β] possiblylinux127@lemmy.zip 1 point 2 years ago (1 child) The problem is that both Rust and Go are huge. The compiled binaries are bigger and the compilers themselves and slower and more resource intensive. The current benefit to C is that is lean and compiles quickly. permalink fedilink source parent hideshow 2 child comments replies: [β] Zangoose@lemmy.world 5 points 2 years ago* Rust is only huge because it doesn't have an ABI. If you had an ABI (and didn't have to compile every single dependency into the binary) the binary sizes would probably drop a lot to the point where they're only slightly bigger than a C counterpart Edit: I don't know if Go has an ABI but they also include a runtime garbage collector in their binaries so that probably has something to do with it. permalink fedilink source parent
[β] Zangoose@lemmy.world 5 points 2 years ago* Rust is only huge because it doesn't have an ABI. If you had an ABI (and didn't have to compile every single dependency into the binary) the binary sizes would probably drop a lot to the point where they're only slightly bigger than a C counterpart Edit: I don't know if Go has an ABI but they also include a runtime garbage collector in their binaries so that probably has something to do with it. permalink fedilink source parent
