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…
Thoughts on Rust bloat
51–60 of 313 posts
Re: Thoughts on Rust bloat
#52Use 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…
Re: Thoughts on Rust bloat
#53Earlier quoted context omitted.
The primary way I can see to address this is to make packaging more difficult. Are there other steps that a language can take to avoid this problem?
A few ideas: 1) Remove the ability to unpublish / yank crates. A published crate should be immutable, but the crate's metadata should always be updateable by the maintainer. 2) Improve the metadata that describes a crate so that it is easy to tell if a crate should be used. For example, is the crate beta quality? Was a serious error found in the crate and it needs to be marked as "not safe"? Is it a Long-Term Support…
Re: Thoughts on Rust bloat
#54At 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…
I think the size of the standard library is just one of possibly many contributing factors that leads to a large number of dependencies. I think a part of it is culture, but another part of it is that the tooling _enables_ it. It's so incredibly easy to write some code, push it to crates.io and let everyone else use it. That's generally a good thing, but it winds up creating this spiral where there's almost no backpressure _against_ including a dependency in a project. This means there's very little standing in the way of letting the fullest expression of DRY run wild. There are some notable examples in the NPM ecosystem where it reaches ridiculous levels. But putting the extremes aside, there's a ton of grey area and it can be pretty difficult to convince someone to write a bit more code when something else might work off the shelf. (And I mean this in the most charitable way possible. I find myself in that situation.)
I do hope we can turn the Rust ecosystem around and stop regularly having dependency trees with hundreds of crates, but it's going to be a long and difficult road. For example, not everyone even agrees with my perspective that this is actually a bad thing.
Re: Thoughts on Rust bloat
#55>the release binary is now 5.9M A typical smartphone ships with around 10,000 times this much storage capacity and enough RAM to hold it 100 times over. This is bloat? I mean, I get it, the binary used to be only 2MB, 1/3rd the size. But are numbers this low really worth worrying about? I think a GUI app in 6MB is hugely impressive. I genuinely thought he was going to say it was 100MB or something higher.
I think a GUI app in 6MB is hugely impressive. You think that because nobody cares about bloat anymore, so everything else is large.
For example, I keep Facebook off my phone, and when I need to download it (for example to rsvp for an event) the app is ~100MB, which means 1> I can’t even do it unless I’m on wifi and 2> it’s slow even there.
I’m having trouble understanding the practical impact of 6MB. Many web pages are larger than that. Even on the Mac I bought in 1994, that would have been a reasonable size for an application (and it only shipped with 120MB hard drive).
But maybe I’m missing something. Some folks have mentioned CPU caches which is interesting — is that the problem?
Re: Thoughts on Rust bloat
#56At 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…
Re: Thoughts on Rust bloat
#57Earlier quoted context omitted.
I think a GUI app in 6MB is hugely impressive. You think that because nobody cares about bloat anymore, so everything else is large.
If you want to code a large app in C with X Athena Widgets or Win32 you're welcome to do so.
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.
Re: Thoughts on Rust bloat
#58Earlier quoted context omitted.
A few ideas: 1) Remove the ability to unpublish / yank crates. A published crate should be immutable, but the crate's metadata should always be updateable by the maintainer. 2) Improve the metadata that describes a crate so that it is easy to tell if a crate should be used. For example, is the crate beta quality? Was a serious error found in the crate and it needs to be marked as "not safe"? Is it a Long-Term Support…
Ironically, "no trivial crates" is almost exactly the opposite of what the article seems to want, which is only small crates so you're not importing lots of needless bloat. It's hard to please everyone!
Re: Thoughts on Rust bloat
#59Earlier 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…
There are a lot of us out there with dev and prod environments that aren’t allowed to be connected to the Internet or otherwise strictly controlled. Languages that rely on me downloading packages are mostly dead in the water at my workplace.
Re: Thoughts on Rust bloat
#60Earlier 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…
There are a lot of us out there with dev and prod environments that aren’t allowed to be connected to the Internet or otherwise strictly controlled. Languages that rely on me downloading packages are mostly dead in the water at my workplace.