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

Thoughts on Rust bloat

raphlinus.github.io

Post reply on HN
Print view View original

201–210 of 313 posts

Re: Thoughts on Rust bloat

#201

Post by throwaway8941 »

kd5bjo wrote: post #192
swsieber wrote: post #158

Earlier quoted context omitted.

> The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means you can develop a degree of mastery over it. The rust ecosystem has done well to converge on certain crates as sort of replacement for missing std features. In practice (at least in the rust ecosystem), I only need to learn one interface for: * regex (regex) * serializat…

As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months. Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes exp…

Because it's "reqwest", not "request".

All these libraries are very well known within the community and are what I would come up with as a complete outsider (I don't think I've written more than a hundred lines of Rust code to this date).

You can also find some pointers here:

https://github.com/rust-unofficial/awesome-rust

https://lib.rs

Re: Thoughts on Rust bloat

#202

Post by asgeir »

leggomylibro wrote: post #21
pornel wrote: post #12

It looks like the author is most bothered by compile times of dependencies. Cargo needs to do better with shared caches (so you compile each dep at most once per machine) or ability to get precompiled crates (so you don't even compile it). Incremental improvements of compiler speed or trimming of individual dependencies won't bring the 10x improvement it needs.

One of the biggest issues that I face with Rust is that its builds are enormous, and I often work on machines with limited disc space. The actual binary sizes are fine - even with embedded devices that have I really appreciate Rust's inclusive approach to learning and teaching, but I can't justify using it for education on ultra-affordable machines for that reason. People often scatter one-off projects all over the p…

Have you considered doing something like this:

  cargo build --target-dir ~/build-artifacts/$(basename $(pwd))
Then you can have something like this in your ~/.config/user-tmpfiles.d/clean_build.conf

  d /home/user/build-artifacts - - - 1d -
You can then do cleanup by calling

  systemd-tmpfiles --user
Or you can use the tmpfiles timer

  systemctl enable --user --now systemd-tmpfiles-clean.timer

Re: Thoughts on Rust bloat

#203

Post by roblabla »

throwaway8941 wrote: post #201
kd5bjo wrote: post #192

Earlier quoted context omitted.

As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months. Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes exp…

Because it's "reqwest", not "request". All these libraries are very well known within the community and are what I would come up with as a complete outsider (I don't think I've written more than a hundred lines of Rust code to this date). You can also find some pointers here: https://github.com/rust-unofficial/awesome-rust https://lib.rs

There's actually a more official resource: the rust cookbook[0]. This is maintained by the rust-lang team (rust-lang-nursery is an official place for crates maintained by the rust language maintainers).

[0]: https://rust-lang-nursery.github.io/rust-cookbook/

Re: Thoughts on Rust bloat

#204

Post by roblabla »

Freak_NL wrote: post #198
kd5bjo wrote: post #192

Earlier quoted context omitted.

As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months. Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes exp…

That sounds like something that could be solved by having crates.io provide a curated list of common popular crates for certain features. That is, this seems to be mostly a documentation issue.

This was attempted by the Libz Blitz back in 2017. See the rust-cookbook: https://rust-lang-nursery.github.io/rust-cookbook/ .

I agree that this should be better documented and probably more integrated with crates.io somehow.

Re: Thoughts on Rust bloat

#205

Post by xenocratus »

kd5bjo wrote: post #200
Freak_NL wrote: post #198

Earlier quoted context omitted.

That sounds like something that could be solved by having crates.io provide a curated list of common popular crates for certain features. That is, this seems to be mostly a documentation issue.

It’s really a reputation bootstrapping problem, for which popularity can be a useful proxy. For me to use third-party code, I have to trust that the future behavior of the developers will be reasonable: I want my side projects that don’t get touched for months or years to still mostly work when I get back around to them. Not everyone or every project will have the same desires, though. Sometimes, a fast-moving experi…

I'm not sure I follow these concerns about "working in the future" - as long as you specify versions that work for you in your Cargo.toml file, that should work at any point in the future given that you use Rust 1.x.

If you'll want to update to always be on the latest version of each crate, well that discomfort about them potentially not working is part of the price.

Re: Thoughts on Rust bloat

#206

Post by atoav »

burntsushi wrote: post #54
ajxs wrote: post #40

At the risk of being slightly tangential, I've been sorely wanting to air this particular grievance with Rust for some time. It's somewhat related, since the author mentions their package system. Its package ecosystem isn't nearly in the horrible state that node's is, but having a package system shouldn't be a substitute for designing a useful standard library for a language. I think that the attraction to 'small lan…

Opinions on this are a dime a dozen. You often see the reverse of it too, for example, you might have heard that "Python's standard library is where things go to die." You could just as easily call that a "terrible error." The fact that Python's standard library has an HTTP client in it, for example, doesn't stop everyone from using requests (and, consequently, urllib3) for all their HTTP client needs. So despite the…

I am a Rust user myself and I think one major problem is that beeing on crates.io say nothing about the quality of code. I never published a single crate myself because in my eyes to be worth published a crate should work decently.

That beeing said, I think the whole Rust userbase would benefit from having some sort of collection of well tested crates and strictly divide between private, work in progress and production crates.

Re: Thoughts on Rust bloat

#207

Post by jokoon »

I just don't feel like rust can replace C/C++, because the syntax is not simple enough. Rust has a lot of cool things, but to me syntax simplicity is more important.

Maybe I have a hard time adapting myself to rust? Maybe my brain is too much "wired" to a C style syntax. It still seems that to me, C-style syntax is just better.

I would rather prefer a C++-like language that breaks down from backward compatibility with C while keeping its simplicity, has STL containers, and is simpler to read and use.

Rust is cool, but I'm just curious if it can really be adopted for large project to justify rewriting existing code.

Re: Thoughts on Rust bloat

#208

Post by kd5bjo »

xenocratus wrote: post #205
kd5bjo wrote: post #200

Earlier quoted context omitted.

It’s really a reputation bootstrapping problem, for which popularity can be a useful proxy. For me to use third-party code, I have to trust that the future behavior of the developers will be reasonable: I want my side projects that don’t get touched for months or years to still mostly work when I get back around to them. Not everyone or every project will have the same desires, though. Sometimes, a fast-moving experi…

I'm not sure I follow these concerns about "working in the future" - as long as you specify versions that work for you in your Cargo.toml file, that should work at any point in the future given that you use Rust 1.x. If you'll want to update to always be on the latest version of each crate, well that discomfort about them potentially not working is part of the price.

If I come back to something, it’s because I want to resume active development. Keeping a dependency pinned at an old version makes that more difficult in various ways, so I personally value forward compatibility.

Not everyone does, and that’s fine. I just want to know what a library developer’s stance on it is before I try to use their library.

Re: Thoughts on Rust bloat

#209

Post by orf »

BubRoss wrote: post #130
orf wrote: post #84

Earlier quoted context omitted.

Arguing about 10KB or 100KB applications on a comment page that's 40kb in size is somewhat silly. It's _worth_ it to trade 1mb, 10mb or 100mb of app size in some cases. That's why you don't hand-craft your "simple 100kb guis" in assembly and have them only be 1kb. Exactly the same principle applies here. Plus, realistically, users don't care. Not one bit. That's why Slack is out here capturing the market, while some…

The reason that it isn't silly is that people keep saying these larger sizes are necessary when anyone with some perspective and history in computers knows that it's ridiculous. You can say users don't care about bloat and speed, but when they have an alternative that is clearly not the case. uTorrent destroyed the market share of other torrent clients by being lightning fast and tiny. Chrome captured market share of…

I never said users don’t care about speed, and bloated binaries do not mean something is slower.

Also, iteration speed is something else users care about.

Re: Thoughts on Rust bloat

#210

Post by atoav »

sgentle wrote: post #159
burntsushi wrote: post #54

Earlier quoted context omitted.

Opinions on this are a dime a dozen. You often see the reverse of it too, for example, you might have heard that "Python's standard library is where things go to die." You could just as easily call that a "terrible error." The fact that Python's standard library has an HTTP client in it, for example, doesn't stop everyone from using requests (and, consequently, urllib3) for all their HTTP client needs. So despite the…

I feel like the role of a standard library has become kind of overloaded. Back when you had to manage all your dependencies yourself, having that baseline of functionality bundled with the language and maintained by its authors was a logistical necessity. You just don't have time to chase deps for every little thing. But in the modern world, I agree with the small language people: the logistical problem is dead. Almo…

The role of the standard library is entangled with the role of the language as a whole. Many people use tbe python interpreter as a sort of advanced calculator. If batteries weren’t included there this whole usecase would suffer.

For a language like Rust this looks different..

Post reply on HN