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

81–90 of 107 posts

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#81

Post by bscphil »

Aurornis wrote: post #12
zadokshi wrote: post #10

Earlier quoted context omitted.

Saying part of the problem is “using too many dependencies” is not an overly helpful thing if the ecosystem keeps on trying to download 3Gb of build dependencies because you tried to use some simple little library. The problem is obvious, it’s the solution that is much more difficult.

> 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 you build them.

To take the last Rust project I built, magic-wormhole.rs [1], the source code I downloaded from Github was 1.6 MB. After running `cargo build --release`, the build directory is now 618 MB and there's another 179 MB in ~/.cargo, for a total of 800 MB used.

All this to build a little command line program that sends and receives files over the network over a simple protocol (build size 14 MB). God forbid I build something actually complicated written in Rust, like a text editor.

[1] https://github.com/magic-wormhole/magic-wormhole.rs

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#82

Post by tialaramex »

fl0ki wrote: post #64
tialaramex wrote: post #52

Earlier quoted context omitted.

I believe the menu of options is undesirable until you actually know you have requirements you can evaluate them against. As much as possible even if I do have a choice, there should be a default and I needn't be asked. When I make a Rust project, cargo notices I have git and, since I didn't say otherwise, it mints a Git repo for the new project automatically. It doesn't insist on asking if I want one, and then askin…

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 choice only makes sense if either I can't tell you anything more specific than impl IntoIterator or I already know I intend to make a change later. So these days I almost always write down what exactly is returned unless either I can't name it or no reasonable person would care.

For serde in particular my guess is that if you need lots of dynamism serde is the wrong approach even though it's popular. It might be interesting to build a different project which focuses on dynamic dispatch for the same work and tries to re-use as much of the serde eco-system as possible. Not work which attracts me though.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#83

Post by SushiHippie »

rwmj wrote: post #20
amelius wrote: post #18

How many % of the kernel is Rust now, in terms of LoC?

Rust: 20,887 lines C: 33,351,596 lines (That's just doing 'wc -l' rather than using any proper code metrics tool)

I've run tokei [0] on the Linux git repository on the latest commit [1] and this was the output:

  ===============================================================================
   Language            Files        Lines         Code     Comments       Blanks
  ===============================================================================
   C                   33553     23772322     17694564      2662642      3415116
   C Header            24554      9562920      7395591      1436546       730783
   Device Tree          5041      1512839      1240129        76384       196326
   ReStructuredText     3473       711669       539971            0       171698
   JSON                  788       443098       443096            0            2
   YAML                 3905       433860       352107        16626        65127
   GNU Style Assembly   1317       372131       271873        55613        44645
   Shell                 894       172036       120033        21590        30413
   Plain Text           1739       151033            0       123992        27041
   Makefile             2946        76889        52985        12355        11549
   Python                203        68545        54627         4452         9466
   SVG                    74        49420        48159         1171           90
   Perl                   59        43992        34124         4074         5794
   Happy                  10         6069         5359            0          710
   Assembly                5         3319         3065            0          254
   C++                     5         2138         1860           61          217
   BASH                   59         1943         1318          335          290
   Unreal Script           5          707          445          158          104
   ASN.1                  16          660          445           87          128
   Autoconf                5          429          373           26           30
   LD Script               8          376          288           29           59
   CSS                     3          295          172           69           54
   Gherkin (Cucumber)      1          291          199           58           34
   TeX                     1          236          156           74            6
   XSL                    10          200          122           52           26
   HEX                     2          173          173            0            0
   Module-Definition       2          128          113            0           15
   C++ Header              2          125           59           55           11
   RPM Specfile            1          108           93            1           14
   Objective-C             1           89           72            0           17
   Vim script              1           42           33            6            3
   Markdown                1           36            0           27            9
   Automake                3           31           23            3            5
   Ruby                    1           29           25            0            4
   INI                     2           13            6            5            2
   TOML                    1           12            2            9            1
   Apache Velocity         1           12           12            0            0
   CMake                   2            8            8            0            0
  -------------------------------------------------------------------------------
   Rust                   64        12637         9489         1612         1536
   |- Markdown            55         8243          808         5557         1878
   (Total)                          20880        10297         7169         3414
  -------------------------------------------------------------------------------
   HTML                    2           28           22            3            3
   |- JavaScript           1            7            7            0            0
   (Total)                             35           29            3            3
  ===============================================================================
   Total               78760     37400888     28271191      4418115      4711582
  ===============================================================================
So If we would only count code and not comments, it is only 9489 LoC Rust. Which would be about 0.03% and if we take all lines and not only LoC it would be around 0.05%

[0] https://github.com/XAMPPRocky/tokei

[1] https://github.com/torvalds/linux/commit/b401b621758e46812da...

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#84

Post by cout »

raoulkent wrote: post #80
cout wrote: post #77

Earlier quoted context omitted.

It would be nice if it fit on a standard size 1.44MB floppy, but given that I haven't used a floppy drive in about a decade, yeah I guess it doesn't matter much.

Just out of interest, what kind of systems do you work on if you've been using floppy discs in the last 25+ years?

I think my current motherboard does not have pins for a floppy drive, but every motherboard I've owned before that does. I just kept moving the floppy drive from chassis to chassis every time I upgraded just in case I needed it. IIRC the last time I used a floppy was either to archive old data to CD-ROM or boot the computer when I couldn't find a USB thumb drive.

I do still own my first computer, an IBM PS/2 Model 50Z, which still has its original floppy drive. Other parts I upgraded -- the 286 was replaced with a 386 SX/Now!, the 30MB ESDI was upgraded to 100MB, and it now has a full 2MB of RAM. I keep the floppy drive because it reads disks that no other floppy drive has been able to read.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#85

Post by pdimitar »

surajrmal wrote: post #14
zadokshi wrote: post #10

Earlier quoted context omitted.

Saying part of the problem is “using too many dependencies” is not an overly helpful thing if the ecosystem keeps on trying to download 3Gb of build dependencies because you tried to use some simple little library. The problem is obvious, it’s the solution that is much more difficult.

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.

The market and your boss do not care about that. They want tasks X and Y done. You have no time to vet 15 alternatives and pick the most frugal one in terms of binary size. Not to mention that for many tasks you have no more than 3-4 alternatives anyway, and none of them prioritize binary size. What are you going to do? Roll your own? Deadline is looming ever closer, I hope you can live without sleep for several days then.

We all know the ideal theory.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#86

Post by pdimitar »

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…

I am not a fan of this as well but you have to consider that a good part of these are caches.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#87

Post by MuffinFlavored »

charcircuit wrote: post #73
rekado wrote: post #47

Earlier quoted context omitted.

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

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?

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#88

Post by saghm »

charcircuit wrote: post #74
saghm wrote: post #55

Earlier quoted context omitted.

I was confused when reading this because I was pretty sure that using other allocators had been supported for a while in Rust. From refreshing myself on the details, it seems that replacing the default allocator is stable ( https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html ), but the API for arbitrary allocators (which includes stuff like being able to do "zero-size" allocations) is not yet stable ( https://…

More importantly allocator_api adds try_new which means you can handle allocation errors.

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.

Re: The Linux Kernel Prepares for Rust 1.77 Upgrade

#89

Post by LegionMammal978 »

saghm wrote: post #88
charcircuit wrote: post #74

Earlier quoted context omitted.

More importantly allocator_api adds try_new which means you can handle allocation errors.

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().
Post reply on HN