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

231–240 of 313 posts

Re: Thoughts on Rust bloat

#231

Post by fnord123 »

majewsky wrote: post #216
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…

My main gripe with crates.io is that they allowed everyone to take every name. The "foo" crate just belongs to the first person who took (or squatted) that name, regardless of whether that person actually implements a nice library under that name. What they should've done is allow uploads only to " / ". So if I decide to make a regex crate, it's called "majewsky/regex" at first and Alice can make "alice/regex" and Bo…

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.regex. Then you can have your com.github.majewsky.regex.

Re: Thoughts on Rust bloat

#232

Post by burntsushi »

pjmlp wrote: post #175
burntsushi wrote: post #109

Earlier quoted context omitted.

At least from a licensing perspective, you should be all set. Virtually everything in the Rust ecosystem is permissively licensed. Trustworthy is another thing altogether though. How do you handle this process in C and C++? Both of those languages have fairly spartan standard libraries as well.

Actually they don't, C standardization just dumped that standard library into POSIX instead, which I why all major OS end up supporting POSIX if they want to make C developers feel at home. And you usually see them cursing the platforms that don't care about POSIX support. And ISO C++ has repented themselves from following C's footsteps and have been improving the standard library since C++11, mostly by integrating b…

I don't understand what point you're trying to make. All I did was ask a simple question: if trust in Rust is hard, how do you handle trust in other ecosystems? The details on exactly how big or how small the standard libraries are (or why they are that way) are less important for this particular question. Consider the size of Python's standard library vs C or C++ or Rust. The size of C or C++ is much closer to Rust's size than Python's size.

Also, while some of your historical context is interesting, I don't really appreciate your editorialization, which I often find is off the mark personally.

Re: Thoughts on Rust bloat

#233

Post by tikkabhuna »

bluejekyll wrote: post #113
sanderjd wrote: post #86

Earlier quoted context omitted.

I think not anymore since java.time - which is incredibly similar to Joda - came around? This is actually an illustrative example of the process I like and hope rust will develop over time: let the community reach a consensus on the best third party libraries things, then consider pulling them in to or at least taking the best parts of their APIs for the standard library.

But won’t the community converge on that anyway, and in a similar amount of time? So why add it to the stdlib?

Other Java stdlib packages can't depend on Joda-time. If it wasn't added and I used joda-time I'd have to convert to the old datetime classes if I wanted to use it with stdlib packages.

Another example was CompletableFutures which were inspired by ListenableFutures from Guava.

I can now use these with guarantees that they will be stable as Java has strong commitments to backwards compatibility.

Re: Thoughts on Rust bloat

#234

Post by pjmlp »

burntsushi wrote: post #232
pjmlp wrote: post #175

Earlier quoted context omitted.

Actually they don't, C standardization just dumped that standard library into POSIX instead, which I why all major OS end up supporting POSIX if they want to make C developers feel at home. And you usually see them cursing the platforms that don't care about POSIX support. And ISO C++ has repented themselves from following C's footsteps and have been improving the standard library since C++11, mostly by integrating b…

I don't understand what point you're trying to make. All I did was ask a simple question: if trust in Rust is hard, how do you handle trust in other ecosystems? The details on exactly how big or how small the standard libraries are (or why they are that way) are less important for this particular question. Consider the size of Python's standard library vs C or C++ or Rust. The size of C or C++ is much closer to Rust'…

My point is that although many only think about ISO C libc when talking about C's standard library, the reality is that with a few exceptions, libc always goes alongside POSIX across the large majority of platforms with a C compiler.

So in reality POSIX complements libc as C's "runtime platform", even though ISO C never considered to make libc that big.

My historical context is how I experienced how things went, throughout the media we had available at the time.

I surely welcome factual corrections when I fail off the mark.

Everyone benefits from learning proper history facts.

Re: Thoughts on Rust bloat

#235

Post by nicoburns »

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 really. Rust supports 8 bit microcontrollers. Lot's of libraries, including parts of the standard library make no sense on these kind of platforms.

The standard library and 3rd party crates generally have excellent compatibility across mainstream platforms.

Re: Thoughts on Rust bloat

#236

Post by Macha »

anp wrote: post #184
vunie wrote: post #105

Earlier quoted context omitted.

The request here is for a simpler API. I and many others would be more than happy to get a function that returns a random u64. No traits, no crippling commitments to a specific API design.

The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.

Which is fine. Not everything needs SecureRandom. I'd wager more code using random numbers is for A/B tests, sample data generation or video games than people implementing crypto.

I get that security people don't want non-secure RNGs to exist out of fear that someone might try implement security related functions out of them but why should I care if I just want to choose between 3 types of enemies this wave?

Re: Thoughts on Rust bloat

#237

Post by stdbrouw »

mantap wrote: post #151
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…

Python's standard library is where things go to die because of the terrible adhoc versioning system (the module name is the version number) and dynamic typing means they are afraid to change anything. But even then it's still better than having no standard library at all. 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…

In Python, if you're running 3.7.1 then you're also running the standard library for 3.7.1. Sure, I guess it would be possible for a programming language to decouple these things so that it's possible to ask for a particular version of the standard library (in its entirety), or a particular version of a standard library... but then programmers can no longer rely on the standard library to "just work" and "just be there", which is its appeal. If you decouple the standard library from the language, might as well switch to a Rust-like system where you simply give an official stamp of approval to certain packages regardless of who developed them.

Re: Thoughts on Rust bloat

#238

Post by pjmlp »

nicoburns wrote: post #235
pjmlp wrote: post #226

Earlier quoted context omitted.

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

Not really. Rust supports 8 bit microcontrollers. Lot's of libraries, including parts of the standard library make no sense on these kind of platforms. The standard library and 3rd party crates generally have excellent compatibility across mainstream platforms.

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

Re: Thoughts on Rust bloat

#239

Post by Macha »

majewsky wrote: post #216
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…

My main gripe with crates.io is that they allowed everyone to take every name. The "foo" crate just belongs to the first person who took (or squatted) that name, regardless of whether that person actually implements a nice library under that name. What they should've done is allow uploads only to " / ". So if I decide to make a regex crate, it's called "majewsky/regex" at first and Alice can make "alice/regex" and Bo…

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.

Re: Thoughts on Rust bloat

#240

Post by ChrisSD »

anp wrote: post #184
vunie wrote: post #105

Earlier quoted context omitted.

The request here is for a simpler API. I and many others would be more than happy to get a function that returns a random u64. No traits, no crippling commitments to a specific API design.

The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.

But the std hashmap implementation[0] already depends on a PRNG via the rand crate[1], and thus OS random (for the initial seed). So it's in the standard library even if you can't use it directly. Which is what makes me think this is an API issue, not an implementation one.

[0]: https://doc.rust-lang.org/std/collections/hash_map/struct.Ra...

[1]: https://docs.rs/rand/0.7.0/rand/rngs/struct.ThreadRng.html

Post reply on HN