Curious, why Rust instead of Zig?
Can Zig guarantee perfect memory safety?
It doesn't need to. Memory issues are easy to catch with good tests and Rust approach to memory safety has its own trade-offs.
The Linux Kernel Prepares for Rust 1.77 Upgrade
101–107 of 107 posts
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#102Earlier quoted context omitted.
GlobalAlloc can be used for fallible allocations: its functions just return a null pointer on failure, as with malloc() and realloc() in C. The main limitations are around the safe heap data structures in the standard library, which don't stably expose any fallible APIs except for Vec::try_reserve().
Hmm, I'd expect that would mean that it's possible to add those APIs today then rather than requiring the `Allocator` trait. Is the idea that the Allocator a parameter (maybe a generic one) when calling `try_new`, so they don't want to stabilize anything now?
The Allocator type is an unstable parameter on the heap type; Vec is unstably Vec, Arc is unstably Arc, and so on. (The allocator "A" defaults to Global, which is an Allocator that forwards to the registered GlobalAlloc.) I think the Linux kernel also wants an Allocator trait for other reasons than fallibility, such as allocating different kinds of objects on different heaps.
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#103Earlier quoted context omitted.
It's not a problem when you compare it to C. You have few available dependencies to choose from with C. If you are equally picky and constrain yourself to parts of the ecosystem which care about binary size, you still have more options and can avoid size issues. For things like a kernel, it is moot as most deps are simply not possible to use anyway. When you consider the full ecosystem, you need to really compare it…
> If you are equally picky and constrain yourself to parts of the ecosystem which care about binary size, you still have more options and can avoid size issues. What's an example of this for, say, libcurl? On my system it has a tiny number of recursive dependencies, around a dozen. [0] Furthermore if I want to write a C program that uses libcurl I have to download zero bytes of data ... because it's a shared library…
Probably ureq[1].
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#104Earlier quoted context omitted.
> Downloading 3GB of dependencies is not a thing that happens in the Rust ecosystem. Reality is orders of magnitude smaller than that. Assuming they're talking about the built size of dependencies that are left lying around after cargo builds a binary, they're really not exaggerating by much. I have no difficulty of believing that there are Rust projects that leave 3GB+ of dependency bloat on your file system after y…
This is why XCode, Android Studio/NDK, VC++ and co have such huge sizes people complain about, compiled binaries for all major variations of compile flags are part of the download. Also why those GNU/Linux repos are actually multiple DVDs nowadays.
> GNU/Linux repos
I'm not sure I understand your point with these, as of course no one ever installs the complete repository (e.g. all of Debian), because there's a ton of software in it you don't need or want. Assuming you mean the installation media, at the very least Arch Linux is still less than 1 GB.
Moreover, I think the point in comparing the behavior of Rust dependencies with other ecosystems (C, C++, Haskell, Python) is that most of this cruft is left behind in the individual directories used to build the software. I occasionally write programs to solve some problem, or for fun, and usually I have to download nothing at all, because I can rely on the dependencies supplied by my system and already installed on behalf of other programs (yes, I'm well aware that this doesn't cover all use cases). Rust is fundamentally not designed to work that way, and the large build sizes and huge dependency trees have a multiplying effect on that foundational issue.
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#105Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#106Earlier quoted context omitted.
You missed the word "statically" in the post you commented on. Dynamically linked libs rarely contribute heavily to binary bloat
The benefit of statically linking becomes moot when it doesn't reduce the number of dynamically linked libraries. That's the point.
That's not why rust statically links the runtime. The main benefit is that they don't have to try to design and maintain a stable ABI for it. Which is not moot.
More generally, you statically link something to avoid distribution hassles of various kinds, not because you care about the specific number.
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#107Earlier quoted context omitted.
The benefit of statically linking becomes moot when it doesn't reduce the number of dynamically linked libraries. That's the point.
That's not why rust statically links the runtime. The main benefit is that they don't have to try to design and maintain a stable ABI for it. Which is not moot. More generally, you statically link something to avoid distribution hassles of various kinds, not because you care about the specific number.
[deleted]