Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Kernel Prepares for Rust 1.77 Upgrade

phoronix.com

Post reply on HN
Print view View original

91–100 of 107 posts

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#91

Post by charcircuit »

MuffinFlavored wrote: post #87
charcircuit wrote: post #73

Earlier quoted context omitted.

LFS does not need to do all of that. LFS already uses the host computer's C compiler, so it seems just as reasonable to also use the host computer's rust compiler.

Doesn't part of the Rust compliation chain end up using `cc` anyway eventually for like, linking or something? That might not apply at a "system's" level but I'm guessing in the massive Linux compilation job with module support you're making a bunch of object files with exported symbols?

The Linux kernel's build system uses rustc only for making object files.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#92

Post by legobmw99 »

rekado wrote: post #47
horeszko wrote: post #9

Earlier quoted context omitted.

LFS is Linux from Scratch right? ( https://www.linuxfromscratch.org/index.html ) What are the implications of using Rust on building Linux?

The Rust bootstrapping story is ugly. https://guix.gnu.org/blog/2018/bootstrapping-rust/

That honestly doesn’t seem that horrible - particularly compared to some of the nigh-on-impossible tasks like bootstrapping GHC

(For the curious) https://elephly.net/posts/2017-01-09-bootstrapping-haskell-p...

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#93

Post by saghm »

LegionMammal978 wrote: post #89
saghm wrote: post #88

Earlier quoted context omitted.

Ah, that is important. I didn't even notice that wasn't possible in the GlobalAlloc API, but you're definitely right that it's not.

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?

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#94

Post by habibur »

Kamq wrote: post #71
habibur wrote: post #61

Earlier quoted context omitted.

Hello world deps for C : linux-vdso.so.1 (0x00007fff25cb8000) libc.so.6 => /lib64/libc.so.6 (0x00007fe5f08d9000) /lib64/ld-linux-x86-64.so.2 (0x00007fe5f0ae2000) And for Rust linux-vdso.so.1 (0x00007ffc109f9000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8eda404000) libc.so.6 => /lib64/libc.so.6 (0x00007f8eda222000) /lib64/ld-linux-x86-64.so.2 (0x00007f8eda4a8000) Rather Rust has 1 more dynamically linked library…

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.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#96

Post by rekado »

legobmw99 wrote: post #92
rekado wrote: post #47

Earlier quoted context omitted.

The Rust bootstrapping story is ugly. https://guix.gnu.org/blog/2018/bootstrapping-rust/

That honestly doesn’t seem that horrible - particularly compared to some of the nigh-on-impossible tasks like bootstrapping GHC (For the curious) https://elephly.net/posts/2017-01-09-bootstrapping-haskell-p...

That's my blog post!

Yes, the GHC story is also terrible (and just a tad worse than the rust story). The GHC problem is worse largely because the origins of GHC are murky. While it's still possible to get copies of the early GHC versions through the Internet Archive, the code lives firmly in the 1990s and assumes that you have access to long lost Haskell compilers. Turns out that all these Haskell compilers (with the exception of Hugs) have the same kind of problems that GHC has --- only worse because they are even older, depend on binaries of unreleased previous versions, and are really difficult to build with tools from the last two decades.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#97

Post by pjmlp »

bscphil wrote: post #81
Aurornis wrote: post #12

Earlier quoted context omitted.

> if the ecosystem keeps on trying to download 3Gb of build dependencies because you tried to use some simple little library. Downloading 3GB of dependencies is not a thing that happens in the Rust ecosystem. Reality is orders of magnitude smaller than that. Why are you exaggerating so much? Some people bristle at the thought of external dependencies, but if you want to do common tasks it makes sense to pull in commo…

> 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.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#98

Post by Thiez »

tialaramex wrote: post #82
fl0ki wrote: post #64

Earlier quoted context omitted.

I agree, but I have yet to see a single real-world example of a Rust project meaningfully reducing its binary size by switching from monomorphization to dynamic dispatch in its own code. Many Rust developers boast that they virtually never use `dyn`, but then still appeal to it when arguing that Rust has dynamic dispatch so monomorphization is an avoidable cost. Sometimes you can provide `T = Arc/Box ` where `T: Foo`…

That's a fair observation, I know when I was first writing Rust my inclination was to return impl IntoIterator from functions which are going to actually return a Vec because hey, if I change my mind you can still iterate over whatever I give you now instead with no code changes. But of course that's an anti-pattern because they are in reality likely to forever just return Vec and knowing that helps you. My early cho…

Note that `impl Foo` return types don't actually cost anything extra with regards to code-size, the compiler knows what the actual type is and there is no dynamic dispatch. Only actual generics have an impact here, and `impl` in a return position doesn't count.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#99

Post by fl0ki »

Thiez wrote: post #98
tialaramex wrote: post #82

Earlier quoted context omitted.

That's a fair observation, I know when I was first writing Rust my inclination was to return impl IntoIterator from functions which are going to actually return a Vec because hey, if I change my mind you can still iterate over whatever I give you now instead with no code changes. But of course that's an anti-pattern because they are in reality likely to forever just return Vec and knowing that helps you. My early cho…

Note that `impl Foo` return types don't actually cost anything extra with regards to code-size, the compiler knows what the actual type is and there is no dynamic dispatch. Only actual generics have an impact here, and `impl` in a return position doesn't count.

Maybe a more specific way to put it is: you only pay for the (combinations of) types you actually use, whether that's in argument position, return position, or even a local binding. So if it's always Vec it's not costing much more in compile time or code size, but if it's sometimes another type then you do now pay for both.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#100

Post by tialaramex »

Thiez wrote: post #98
tialaramex wrote: post #82

Earlier quoted context omitted.

That's a fair observation, I know when I was first writing Rust my inclination was to return impl IntoIterator from functions which are going to actually return a Vec because hey, if I change my mind you can still iterate over whatever I give you now instead with no code changes. But of course that's an anti-pattern because they are in reality likely to forever just return Vec and knowing that helps you. My early cho…

Note that `impl Foo` return types don't actually cost anything extra with regards to code-size, the compiler knows what the actual type is and there is no dynamic dispatch. Only actual generics have an impact here, and `impl` in a return position doesn't count.

The code size cost doesn't live in my code, but in yours.

Because I didn't admit you were getting a Vec, if you actually need a Vec you actually can't just use the one I gave you. You must jump though hoops to turn whatever I gave you into a Vec, bloating your code.

The implementation is pretty clever, it is probably not going to meticulously take my Vec to pieces, throw it away and make you a new one, instead just giving the same Vec. But this trick is fragile, so much better not to even need it.

Post reply on HN