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

81–90 of 313 posts

Re: Thoughts on Rust bloat

#81

Post by stackzero »

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.

I think this reflects the enterprise culture and auditing practices more than anything

Re: Thoughts on Rust bloat

#82

Post by raphlinus »

orf wrote: post #69
raphlinus wrote: post #63

Earlier quoted context omitted.

In my post, I specifically call on proc-macro support (syn and quote) plus rand (not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity) to be added to the Rust standard library. But I feel these are particularly justified because they're already present, just not accessible. Overall, I think Rust's "batteries not included"…

> not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity Are you suggesting including the core `rand` crate with some traits and a basic pseudo-random generator in the stdlib, and allowing other crates to use those traits to implement the many other[1] RNGs? I'm honestly not sure this is a good idea, it seems the rand crate…

I admit, design of a proper random number library API is tricky, and experience from deploying rand will no doubt be invaluable. The point I was trying to make is that some use cases require sophistication such as being able to choose different algorithms, but a lot of the times rand shows up in a build time histogram, it's just because the user wanted some pretty good random numbers; a much simpler API would suffice.

Re: Thoughts on Rust bloat

#83

Post by darksaints »

chc wrote: post #74
quickthrower2 wrote: post #67

Earlier quoted context omitted.

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.

Even in Java, if you're looking to do anything with dates, everyone will tell you to use Joda-Time over java.util.Date.

That's true if you're still on Java 7. java.time.* is the go-to now, and it is very high quality.

Re: Thoughts on Rust bloat

#84

Post by orf »

BubRoss wrote: post #57
Scuds wrote: post #43

Earlier quoted context omitted.

If you want to code a large app in C with X Athena Widgets or Win32 you're welcome to do so.

Fltk can give you a static binary on every platform where simple GUIs are under 100KB. Win32 isn't actually all that bad and getting simple GUI programs with icons under 10KB is completely doable. Thinking that GUIs need to be 6 MB or painful is a complete false dichotomy.

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 other lightweight and exquisitely coded 10kb tool written in C isn't. Because they are shipping features the users want and iterating fast on their memory hungry and bloated platform, while the other one segfaults when there is an unencountered error.

Re: Thoughts on Rust bloat

#85

Post by burntsushi »

raphlinus wrote: post #63
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…

In my post, I specifically call on proc-macro support (syn and quote) plus rand (not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity) to be added to the Rust standard library. But I feel these are particularly justified because they're already present, just not accessible. Overall, I think Rust's "batteries not included"…

I don't necessarily disagree. I have my own pet things that I'd like to see in std too. I've long wanted to see lazy_static in std. Funnily enough, it looks like `once_cell` might wind up being a nicer approach to achieving a similar end, but without using a macro. So if we had added it to std many years ago, we might find ourselves with an API that we regret! It's tough.

With that said, if `syn` finds itself in a spot where it needs to do a breaking change release for a new language feature, then that would be tricky. It sounds like syn's architecture is pretty flexible (non-exhaustive enums), but it's not clear to me that it could support all possible language additions without breaking changes.

Re: Thoughts on Rust bloat

#86

Post by sanderjd »

chc wrote: post #74
quickthrower2 wrote: post #67

Earlier quoted context omitted.

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.

Even in Java, if you're looking to do anything with dates, everyone will tell you to use Joda-Time over java.util.Date.

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.

Re: Thoughts on Rust bloat

#87

Post by hinkley »

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…

> Its package ecosystem isn't nearly in the horrible state that node's is

I propose that the dictionary entry for 'faint praise' be updated to include this example.

Re: Thoughts on Rust bloat

#88

Post by ChrisSD »

orf wrote: post #69
raphlinus wrote: post #63

Earlier quoted context omitted.

In my post, I specifically call on proc-macro support (syn and quote) plus rand (not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity) to be added to the Rust standard library. But I feel these are particularly justified because they're already present, just not accessible. Overall, I think Rust's "batteries not included"…

> not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity Are you suggesting including the core `rand` crate with some traits and a basic pseudo-random generator in the stdlib, and allowing other crates to use those traits to implement the many other[1] RNGs? I'm honestly not sure this is a good idea, it seems the rand crate…

I would like getrandom[0] to be in the standard library. It simply abstracts over the platform random and is even used by the standard library itself.

[0]: https://crates.io/crates/getrandom

Re: Thoughts on Rust bloat

#89

Post by bogdanoff_2 »

andolanra wrote: post #11
Qasaur wrote: post #6

Use polymorphism sparingly I think it is a little ironic that he speaks of performance culture but simutaneously advises to use dynamic dispatch and avoid polymorphism. I can see the justification in non-critical code paths, but serialisation is a pretty important part of most networked software nowadays so I do not think that smaller binaries and faster compilation times (better developer experience) justifies a per…

One thing I like about Rust a lot is that it lets you choose which hit you want to take when it comes to polymorphism. You can manually (and without much difficulty!) prefer dynamic dispatch if it's important to you to keep your binary size small, but you can also choose static dispatch and allow some replicated copies of your parametric code if that's what you want to optimize for. It's also worth noting that if you…

It would be nice if Box implemented Trait. Then we would be able to write the function only once with parametric polymorphism and then at callsite decide if we want to monomorphize for the given type or not.

Re: Thoughts on Rust bloat

#90

Post by anp »

raphlinus wrote: post #82
orf wrote: post #69

Earlier quoted context omitted.

> not all of rand though, just the "give me a random number" functionality that comprises 99% of the use cases but 10% of the implementation complexity Are you suggesting including the core `rand` crate with some traits and a basic pseudo-random generator in the stdlib, and allowing other crates to use those traits to implement the many other[1] RNGs? I'm honestly not sure this is a good idea, it seems the rand crate…

I admit, design of a proper random number library API is tricky, and experience from deploying rand will no doubt be invaluable. The point I was trying to make is that some use cases require sophistication such as being able to choose different algorithms, but a lot of the times rand shows up in a build time histogram, it's just because the user wanted some pretty good random numbers; a much simpler API would suffice…

I agree that in many cases a much simpler API would suffice, but it strikes me as odd to suggest adding a convenient but insufficient-for-security API to the same standard library that protects HashMap against DoS.
Post reply on HN