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

301–310 of 313 posts

Re: Thoughts on Rust bloat

#301

Post by nicoburns »

ajxs wrote: post #289
howdydoo wrote: post #256

Earlier quoted context omitted.

>deployment profiles In other words, not all functions in the stdlib of Ada, Pascal, C and C++ can be used in all possible target environments? Sounds like a failure to quality gate those standard libraries.

I'm not sure if you're just being disingenuous here, but you're right that you're not going to be able to use all functionality from the stdlib of Ada ( and others ) on every possible target, but you were never , ever going to. And Rust certainly won't solve this problem for you. It's not a consequence of poor standard library design either. It might not be immediately obvious, but even C has a runtime library, which…

I don't think the parent was claiming the Rust was better in this regard, just that it was no worse. Other languages also restrict standard library features on some platforms.

Re: Thoughts on Rust bloat

#302

Post by Macha »

apta wrote: post #294
Macha wrote: post #239

Earlier quoted context omitted.

That basically just moves the problem to a land grab for the group name. Because people don't think Alice/regex looks professional enough, there will be a rush for regex/regex.

You don't see that with Java/Maven.

Thats because it's based on domain names and the land grab has already occured prior to names being chosen

Re: Thoughts on Rust bloat

#303

Post by Ygg2 »

pjmlp wrote: post #297
Ygg2 wrote: post #296

Earlier quoted context omitted.

Still, it implies C fails, because you don't get POSIX on all available platforms. I think the definition is meaningless. Rust spends huge amount of resources to test itself and its surrounding ecosystem on tier 1 platforms. I'm fairly certain regex from c++ std will run like crap, if at all on something with 4MB of RAM.

Except the small detail that C's POSIX support is much wider than Rust's tier 1 platforms. I am fairly certain that without profiling and defining a test configuration for a set of specific C++ compilers / standard C++ library I won't assert anything about std::regex performance with 4 MB of RAM.

Perhaps. But you're comparing a 26 year old standard for a 47 year old language, to a language that's been stable for 4 years.

Re: Thoughts on Rust bloat

#304

Post by jcelerier »

nickpsecurity wrote: post #300
jcelerier wrote: post #299

Earlier quoted context omitted.

well, I still think that Qt is the better solution, and so by an order of magnitude :-) it allowed me to write the software, which is being used in production in mac / linux / windows, while doing a ph.d. at the same time ; not sure I could have done the same with any of the other options in there (an older version was using JUCE but it was full of problems ; in particular JUCE's software renderer is much less effici…

Oh yeah, I agree. It's a good one. Several folks in the comments called out the author for not bringing it up. Personally, I think the author had a bias where any solution had to be close to the size of the native, standalone app. One thing I wondered about Qt is if there's a way to trim out anything an app doesn't use. Have you seen anything like that?

There's https://qtlite.com

Along with the following shell command :

    grep  --only-matching --no-filename -R 'include '  | cut -f2 -d' ' | sort | uniq
you can quickly see what must stay and what can go

Re: Thoughts on Rust bloat

#305

Post by ameixaseca »

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…

Given there are no infinite resources, one has to choose where to focus. Rust team seems to be focusing on the language and solving hard-to-deal-with but relevant problems - and on evolving the language, which is truly a remarkable feat when you are pushing the boundaries.

Libraries can be implemented by 3rd parties and maybe later adopted as standard libraries or become de-facto standards. That's how it has been done for most popular languages out there, and I think it's a smart decision.

Re: Thoughts on Rust bloat

#306

Post by ameixaseca »

Good points, but I'd like to point out that nothing on this post is Rust-specific.

You can have the same issue if programming in any other language, including C: excessive indirections, inefficient algorithms, bad abstractions, excessive use of unnecessary libraries, etc.

It's indeed easier to "bloat" your resulting binary in C++ or Rust given the easiness to do higher-level abstractions; since you can more easily program complex solutions you also need to consider your design and the trade-offs on your code.

I'd also like to point out that, in comparison:

* Rust bloat is a speck compared to hundreds of megabytes for a similar Python program + runtime including the same amount of code.

* Rust bloat can be mostly optimized away for systems that really care about excess/unused code - you have #![no_std], disabling of backtraces, aborting on panic, and a lot of other optimizations that throw away a big portion of extra functionality not needed for things like embedded. You have little alternative on things like Go besides removing debugging symbols and doing tricks like "dynamic decompression" (which could also be applied to Rust programs to further reduce their size, btw).

Bottom line is: Rust makes it easier for you to "just add a new library" and it also make you more mindful of the bloat, but we need to keep it in perspective.

Re: Thoughts on Rust bloat

#307

Post by pjmlp »

floatboth wrote: post #247
adrianN wrote: post #193

Earlier quoted context omitted.

If today's computers did things a million times better, or did a million more things than 25 years ago, I'd agree with you, but from a user perspective a modern computer is not really all that different from a Windows 3.11 machine. The screens are bigger and we have Internet now, but the experience of, e.g., writing a letter in Word is basically the same.

The screens alone are responsible for a lot of size increases (framebuffers in RAM, high res media) but also, unlike in Windows 3.11, modern Word allows you to mix English, Japanese and Arabic in a document, allows use of a screen reader, and has a thousand features that you personally don't need but everyone has some set of features that they use, and taking away any of them would offend someone .

And me thinking I already was able to do that with Word on NT 4.0 and Dragon NaturallySpeaking.

Re: Thoughts on Rust bloat

#308

Post by tjalfi »

quickthrower2 wrote: post #67
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…

The culture of the programmers comes into it too. In the Java/.NET world devs are happier to take what the core libraries provide. A case in point is how the ORM Entity Framework that comes with .NET has made the older NHibernate (a separate package) obsolete. .NET developers love using the standard libs, but OTOH Microsoft has a lot of resources to create very complete libraries.

My goal for choosing .NET libraries is to minimize the total complexity of our software stack. [0]

I won’t add a library to our stack if we have an existing solution.

Most of our apps are written in C# and use Entity Framework with either ASP.NET MVC or Windows Forms.

I would need an excellent reason to use something else.

[0] https://mcfunley.com/choose-boring-technology

Re: Thoughts on Rust bloat

#309

Post by leggomylibro »

asgeir wrote: post #202
leggomylibro wrote: post #21

Earlier quoted context omitted.

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

That sounds like an interesting idea, thanks! Can that '--target-dir' argument be added in the build.rs script?

Re: Thoughts on Rust bloat

#310

Post by asgeir »

leggomylibro wrote: post #309
asgeir wrote: post #202

Earlier quoted context omitted.

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

That sounds like an interesting idea, thanks! Can that '--target-dir' argument be added in the build.rs script?

It looks like you can set it using a CARGO_TARGET_DIR environment variable or build.target-dir config value. So I guess you could create a $HOME/.cargo/config file with the following in it (letting you skip the --target-dir part):

  [build]
  target-dir = "/home/user/build-artifacts"
But I don't know if the different projects will trample each other that way. If that's the case you could just go with a .cargo/config per-project targeting a subdirectory of the build-artifacts directory.

https://doc.rust-lang.org/cargo/commands/cargo-build.html

https://doc.rust-lang.org/cargo/reference/config.html

Post reply on HN