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

281–290 of 313 posts

Re: Thoughts on Rust bloat

#281

Post by swsieber »

nicoburns wrote: post #218
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…

They probably meant reqwest ( https://github.com/seanmonstar/reqwest ), not request. Reqwest is maintained by the same developer (seanmonstar) as hyper, the de facto standard http library.

Ah, I did. I posted that on my phone. Autocorrect strikes again.

Re: Thoughts on Rust bloat

#282

Post by msbarnett »

heavenlyblue wrote: post #223
msbarnett wrote: post #15

Earlier quoted context omitted.

> It's a little unfortunate that some of the cool features of Rust need to be put into the "use sparingly" category. This is just the reality of engineering -- there are no silver bullets. Sure, it'd be nice if any language could give you the space efficiency of dynamic dispatch with the runtime efficiency of monomorphized generics, but those two things are fundamentally in tension . Neither Rust nor any other langua…

One way to fix it is jitting. I am wondering if Rust has a project of shipping Rust compiler embedded in your executable, so that one could compile sym into code.

> One way to fix it is jitting.

Also not a silver bullet, because there's non-zero costs in memory, CPU overhead, I$, etc to the statistics gathering, stop-and-jit-the-dynamic-call-and-change-the-call-sites and so forth.

In long running server processes this can mostly amortize out nicely over a very long run, but for interactive applications it can add noticeable lag.

Re: Thoughts on Rust bloat

#283

Post by TheCoelacanth »

ninkendo wrote: post #149
pcwalton wrote: post #141

Earlier quoted context omitted.

Even if that library had slow serialization like that of Go, forcing the use of packages to make it faster?

So we'd be no worse off than we are now? And just in that one case?

Except for all of the wasted work for maintainers to maintain the crappy library that has a better replacement outside of the standard library.

Re: Thoughts on Rust bloat

#284

Post by pitaj »

vvanders wrote: post #80
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…

On the flip side Lua is a wonderful language because its small lib lets it go anywhere. We used to run a whole gamestate of a shipped title on PSP in a 400kb block allocation. I've yet to see that in any other dynamic language of consequence.

Statically compiled languages like Rust can have a large a standard library as they want, because only the code that is actually used will get included in the binary.

Re: Thoughts on Rust bloat

#285

Post by steveklabnik »

raphlinus wrote: post #275
steveklabnik wrote: post #263

Earlier quoted context omitted.

We’ll see; it’s not a simple thing. In theory they can move into the standard library, but none ever have. The process exists though.

I can think of a bunch of stuff that has moved or is moving from third party crates into the standard library: parking_lot, hashbrown, (minimal) Future trait. But I agree that no crate has moved wholesale into the standard lib.

parking lot and hashbrown moved their internals, replacing ones that already existed. This is probably a distinction that doesn’t actually matter but in my head it’s different for some reason, thanks for pointing it out :)

Re: Thoughts on Rust bloat

#286

Post by je42 »

raphlinus wrote: post #160
je42 wrote: post #157

I don't understand the advice: "Use async sparingly" It doesn't make sense. Either your complete code base is async or it is not. If you have a single blocking code point in it. It is not async anymore, since it can't handle any other schedule async tasks while waiting for the blocking call.

Probably could have worded it better. I didn't mean, "only use a little bit of async," I agree that doesn't make sense. I meant, "use async if your problem really needs it, otherwise avoid it."

The main thing it is you can't really add async when you need it, because if you have written enough sync code, turning it into async amounts to a major rewrite/refactor of the code including choices for dependencies, code for parallel code execution are different in async etc.

Re: Thoughts on Rust bloat

#287

Post by floatboth »

jokoon wrote: post #273
floatboth wrote: post #252

Earlier quoted context omitted.

Maybe you're looking for D? :) Anyway, what is "not simple" about Rust's syntax?

Using "let thing: type" seems bloated, I prefer the C style "type thing;" ; can also make a lot of difference, which is a little weird. I don't understand why there is both str and String, seems complicated for nothing. Option things are not really clear yet, and I don't understand what is their use, it seems like an alternative to unions, but few developers use unions anyway... Pattern matching seems powerful but I…

Most of the time, just `let thing`. Let (ha) type inference do its thing. Explicit type annotations are for when it fails.

`String` is roughly a Java `StringBuffer`, `&str` is roughly a C++ `string_view`.

Yes, you need to rethink how you write code. Rust relies a lot on the basics of typed functional programming. Reading a Haskell tutorial up until the M word would help a lot. But surely there's a lot of good guides written for Rust specifically.

tl;dr the core concept you're looking for is sum types, aka discriminated/tagged unions. If you're going "up" from C level abstraction, imagine a C union starting with an enum that indicates which value is there. That's essentially what it is at the memory level (modulo optimizations). But conceptually, you just have a "this OR that" type. Pattern matching is how you access values of that kind of type.

https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

Re: Thoughts on Rust bloat

#288

Post by fnord123 »

majewsky wrote: post #268
fnord123 wrote: post #231

Earlier quoted context omitted.

Apparently that was done in the Ruby community and Github "helpfully" uploaded all the Ruby packages to the gems repository meaning all 217 forks of https://github.com/httprb/http became potential gems. But the underlying idea is sound: namespace and federation. Rust should ideally follow Java's solution. And it's completely forward portable: when namespacing is introduced, the crates.io/regex crates become io.crates…

I don't particularly like URL-derived package names, esp. with Go where the repo URL is auto-derived from the package name, because that makes it an absolute pita to move the repo to a new canonical location.

That's not an issue in Java.

Re: Thoughts on Rust bloat

#289

Post by ajxs »

howdydoo wrote: post #256
pjmlp wrote: post #238

Earlier quoted context omitted.

So do Basic, Ada, Pascal, C and C++ as well, and yet they have richer standard libraries, with deployment profiles.

>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 needs to be specific to the architecture and OS that you're targeting. Just for a quick example, `malloc` is going to need to function differently depending on what OS you're running, and if you're targeting a microcontroller with extremely limited RAM it might not even need to be implemented at all.

Re: Thoughts on Rust bloat

#290

Post by Ygg2 »

pjmlp wrote: post #226
Ygg2 wrote: post #195

Earlier quoted context omitted.

No, but not all parts of std run on all supported platforms. To clarify, there are different levels of support on different platforms.

Then it already starts with a failure of quality gate of what goes into std.

Not exactly. Rust can be made to run on 16-bit toaster or even OsIJustWrote. Just because it can be run, doesn't mean Rust std lib devs will support 16-bit toasters or OsIJustWrote.

Each platform has different levels of support. Primary being Windows, Mac and Linux, where every pure Rust crate runs.

Std lib makes certain reasonable assumptions, for which it works e.g. malloc exists and panic! is implenented.

Post reply on HN