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

111–120 of 313 posts

Re: Thoughts on Rust bloat

#111

Post by mwcampbell »

orf wrote: post #78
userbinator wrote: post #66

Earlier quoted context omitted.

I think a GUI app in 6MB is hugely impressive. Windows 3.11 required 4MB of RAM and the whole install took the entire OS with all of its utilities and libraries. A typical smartphone ships with around 10,000 times this much storage capacity and enough RAM to hold it 100 times over. The fact that it can hold that much does not make it right to waste resources. To contrast, video or audio is a good use of the space it…

> Windows 3.11 required 4MB of RAM and the whole install took Sure, and the moon landing used computers with less processing power than your kids calculator. That doesn't mean we should use those to put people on the moon over faster hardware. Does the fact that older, slower and smaller hardware and software once existed mean we should spend time, resources and potentially sacrifice features to... what? Hark back to…

But what if GUI applications that were considered lean and mean in the 90s were common on today's hardware? Wouldn't those applications be really fast and light on resources?

Re: Thoughts on Rust bloat

#112

Post by kbenson »

burntsushi wrote: post #85
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"…

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 sp…

> So if we had added it to std many years ago, we might find ourselves with an API that we regret! It's tough.

That is the ultimate problem of batteries includes vs a small standard library distilled into a specific example.

People used to tout Python's "batteries included" line as positive almost universally a decade and more ago. Then better replacements were developed, and those batteries started looking less appealing.

There's really no escaping that while including any base functionality. Either you include it and portions will be stale later as better interfaces and paradigms are developed, or you don't, and you risk slower adoption and harder usability as people need to figure out solutions for common tasks, even if that solution is as simple as find the crate that provides it. Because eventually that becomes a problem not of finding the crate, but finding the best crate out of the multiple that exist, which itself causes fragmentation of the common developer experience (and thus makes it harder to share knowledge and have a good community).

Re: Thoughts on Rust bloat

#113

Post by bluejekyll »

sanderjd wrote: post #86
chc wrote: post #74

Earlier quoted context omitted.

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.

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

Re: Thoughts on Rust bloat

#114

Post by stuartd »

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.

> .NET developers love using the standard libs

I may not be a typical .Net developer, but my personal feeling is that this is too general and somewhat glib.

If you're inexperienced you will (and should!) choose the default option, if there's one available, and the most commonly used option if there isn't a default. So, if you wanted an ORM, then before EF there was NHibernate. But after a while you become able (from painfully gained experience) to determine what you want from a tool and what trade-offs you want to make, so you might use something like Dapper or no ORM at all.

Personally, I have found some of the MS provided implementations - shall we say - less than optimal. The Unity Framework. EF (which I dearly wish I have never had to suffer using). MSTest. Enterprise Library (oh god ugh).

So I make other - informed - choices about what to use. Some things I keep using because they are 'good enough' and I have a library of utilities and a mental map of how they work - log4net, NUnit - and some things I find I just don't need any more (mocking libraries, for one).

MS still support their provided implementations - as they should - but even their own projects can and do use third-party frameworks rather than the MS provided implementation (for example, Bot Framework used AutoFac (back when I was using it, anyway) [1]) - because their developers have been released from the requirement to exclusively use MS provided frameworks, and are making their own choices about what to use in their projects, and consequently what their users should use when using those tools.

Eventually, of course, if a tool is so crucial that it becomes part of .Net itself - the best example I can think of is dependency injection in .Net Core, which is in Microsoft.Extensions.DependencyInjection - you'd have to be mighty stubborn to use anything else.

One other point: I wouldn't describe NHibernate as 'obsolete', but given their historic and chronic inability to keep their documentation sites live and working ([2] referenced from [3]) it's easy to get that impression. But people are certainly still using it [4]. Just not as many as there used to be.

[1] https://github.com/microsoft/botframework-sdk/issues/938 [2] http://www.nhforge.org/doc/nh/en/index.html [3] https://ayende.com/blog/4139/nhibernate-documentation [4] https://stackoverflow.com/questions/tagged/nhibernate

Re: Thoughts on Rust bloat

#115

Post by ajxs »

sanderjd wrote: post #95
ajxs wrote: post #73

Earlier quoted context omitted.

I would beg to differ with this. The kind of functionality expected from Getopt is fairly standard these days. I also disagree that features like getopt really need to 'evolve' much at this point in time. At the risk of courting controversy here, I'm going to confess that often I just don't want the community involved in the development of a language. On a project I inherited recently ( with the mission to save ) I u…

Who is "the community" and who isn't? Are you sure you trust the core language developers more than people writing libraries?

More often than not, absolutely. It requires a much higher level of competence to design a language and develop a functional compiler than it does to design libraries. There are packages in Node with millions of downloads, packages that are basically ubiquitous in certain domains that are riddled with bugs, with terrible interfaces and documentation. I can even think of libraries I've worked with in Java/C/.net/etc that are just horrific... If the languages themselves were as badly designed as the average library, they'd never succeed.

Re: Thoughts on Rust bloat

#116

Post by jchw »

burntsushi wrote: post #98
jchw wrote: post #62

Earlier quoted context omitted.

You mention Python, but I am pretty sure you've written some popular Go packages, so what is your opinion on the Go standard library? I think it's a good example of 'batteries included' in the right sense. Though, some of the reason its good may just be virtue of the fact that it's newer and there's less rotting packages; I guess only time will tell for sure, but it definitely feels right to me in many cases.

I like Go's standard library. It's well designed. The number of pitfalls is pretty small. I have more thoughts, but they are very hand wavy and ill-formed, so please take them with a grain of salt. One of my theories for why the Go standard library has had as much success as it has, is that it doesn't necessarily provide implementations that go as fast as reasonably possible, and that tends to give more flexibility f…

Thanks, that seems reasonable. I still hope Rust can strike a better balance than it has now, which perhaps will become easier as champions emerge in the ecosystem. (Crossbeam stuff in standard library would be nice.)

Re: Thoughts on Rust bloat

#117

Post by jclulow »

sanderjd wrote: post #91
sansnomme wrote: post #65

Earlier quoted context omitted.

A better choice would be enterprise titans like Java and .NET, more bases are covered. Go's GUI story for example is just endless fragmentation compared to e.g. Java.

Yeah, see, I think it's anachronistic and odd that Java comes with GUI stuff included! That seems niche and better relegated to a library to me.

It wasn't, though, in 1995. Though it is perhaps less fashionable now, it was certainly something a lot of programs used at the time.

Re: Thoughts on Rust bloat

#118

Post by Animats »

Do dynamic libraries really help? They only save space in the case where 1) you are running many different programs and 2) they all use the same libraries in the same versions. If you're running multiple copies of the same program, they share code, at least on Linux.

Re: Thoughts on Rust bloat

#119

Post by mhink »

hinkley wrote: post #101
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…

I think it's considered old hat by now for JITs in languages with polymorphism to inline a little bit of dynamic dispatch code into the call sites. The branch predictor gets to work its magic and removes the call overhead in a high number of cases. I think I read somewhere that Javascript engines do something similar, with some extra code to de-optimize when you fiddle with the object prototype.

I’m not super familiar with the details, but all the the major Javascript engines definitely do extremely involved runtime optimizations, and I wouldn’t be surprised at all if the case you described is one of them.

Re: Thoughts on Rust bloat

#120

Post by mmastrac »

burntsushi wrote: post #109
galangalalgol wrote: post #108

Earlier quoted context omitted.

I think I get the tradeoffs but while my company would be a perfect fit for rust, we do all our development on an airgapped network. Custom registries are a thing now, but picking and choosing which packages our IT will consider trustworthy and then taking the subset of that with a license our legal will approve an then prunimg things with dpendencies that are now missing is a huge task that needs to happen at regula…

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.

> Virtually everything in the Rust ecosystem is permissively licensed.

I just did our license audit and 100% of our shipped deps were Apache | MIT. If you can clear those two licenses with legal, you should be good to go for virtually any crate.

Might be worth releasing my one liner for this if anyone else finds it useful.

Post reply on HN