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

291–300 of 313 posts

Re: Thoughts on Rust bloat

#291

Post by ajxs »

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

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 canonical example I was thinking of was this: https://doc.rust-lang.org/nomicon/ffi.html We only get as far as the second paragraph before the official manual is recommending that we use a 3rd party crate. I understand that this crate is made by the Rust developers, but this doesn't seem like a good approach to me.

Re: Thoughts on Rust bloat

#292

Post by [deleted] »

majewsky wrote: post #219
spieglt wrote: post #121

Earlier quoted context omitted.

If Rust had a standard library like Go's I'd love it even more.

Go's standard library works for Go because it has a rather sharp focus on implementing web services. It's worthless for implementing a GUI application, or a particle physics simulation, or a PID-1 daemon. Rust has a much broader aim, so a stdlib accommodating all of its usecases would be as comically huge as Python's, with all the problems that come from that.

[deleted]

Re: Thoughts on Rust bloat

#293

Post by spieglt »

majewsky wrote: post #219
spieglt wrote: post #121

Earlier quoted context omitted.

If Rust had a standard library like Go's I'd love it even more.

Go's standard library works for Go because it has a rather sharp focus on implementing web services. It's worthless for implementing a GUI application, or a particle physics simulation, or a PID-1 daemon. Rust has a much broader aim, so a stdlib accommodating all of its usecases would be as comically huge as Python's, with all the problems that come from that.

It's also good for crypto, image processing, logging, file compression, and other commonly useful things. Go does have an emphasis on network services but is not limited to that.

"a stdlib accommodating all of its usecases would be as comically huge as Python's, with all the problems that come from that."

That's a straw man. I don't want a stdlib like Python's, I want one like Go's.

Re: Thoughts on Rust bloat

#294

Post by apta »

Macha wrote: post #239
majewsky wrote: post #216

Earlier quoted context omitted.

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.

You don't see that with Java/Maven.

Re: Thoughts on Rust bloat

#295

Post by snovv_crash »

heavenlyblue wrote: post #221
raphlinus wrote: post #100

Earlier quoted context omitted.

Right, I see your point here. There are non-trivial issues that need to be worked out, which I'm sure is one reason it's not in the library yet. Another (mentioned elsewhere) is that it takes time to converge on what a good API might look like.

Well, with non-std I can always downgrade or upgrade the library. With std I am bounded by the current language version.

You can only down or upgrade if uour dependencies don't depend on it too.

Having a defacto standard library has more issues IMO than a real standard library.

Re: Thoughts on Rust bloat

#296

Post by Ygg2 »

pjmlp wrote: post #250
floatboth wrote: post #246

Earlier quoted context omitted.

Since when does libc include "rich" things like regex, serialization and http?? Even C++ standard lib is mostly containers and algorithms. libc is barely a standard library, it's almost nothing.

C might not include those specific examples, but POSIX + libc already include plenty of stuff. C++ surely does include regex, with serialisation and http scheduled for C++23, or with luck with a TR as intermediate delivery. Although serialisation depends on static reflection being finalized as well.

Still, it implies C fails, because you don't get POSIX on all available platforms.

I think the definition is meaningless. Rust spends huge amount of resources to test itself and its surrounding ecosystem on tier 1 platforms.

I'm fairly certain regex from c++ std will run like crap, if at all on something with 4MB of RAM.

Re: Thoughts on Rust bloat

#297

Post by pjmlp »

Ygg2 wrote: post #296
pjmlp wrote: post #250

Earlier quoted context omitted.

C might not include those specific examples, but POSIX + libc already include plenty of stuff. C++ surely does include regex, with serialisation and http scheduled for C++23, or with luck with a TR as intermediate delivery. Although serialisation depends on static reflection being finalized as well.

Still, it implies C fails, because you don't get POSIX on all available platforms. I think the definition is meaningless. Rust spends huge amount of resources to test itself and its surrounding ecosystem on tier 1 platforms. I'm fairly certain regex from c++ std will run like crap, if at all on something with 4MB of RAM.

Except the small detail that C's POSIX support is much wider than Rust's tier 1 platforms.

I am fairly certain that without profiling and defining a test configuration for a set of specific C++ compilers / standard C++ library I won't assert anything about std::regex performance with 4 MB of RAM.

Re: Thoughts on Rust bloat

#298

Post by kanishkarj »

I'm naive to rust, but I do get your concern. For a small part in a project, I used a tokio based library. And it just exponentially increased my build time.

What about if rust could support something like dynamic Linking/loading. Like have some crates globally installed and while building we could link to the global one instead of locally getting all the crates. Like C/C++does it right?

Re: Thoughts on Rust bloat

#299

Post by jcelerier »

nickpsecurity wrote: post #280
jcelerier wrote: post #190

Earlier quoted context omitted.

> Plus, realistically, users don't care. Not one bit. I disagree. I develop an audio workstation - https://ossia.io ; the total size is between 50 and 100 megabytes depending on the platforms. It uses Qt and LLVM and is itself around 500kloc so I'm already around the lower limits of what I can do. My users, & much people on the internet keep comparing it in size to Reaper, another DAW where the binary is around 10 me…

You might find this article interesting: http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trai...

well, I still think that Qt is the better solution, and so by an order of magnitude :-) it allowed me to write the software, which is being used in production in mac / linux / windows, while doing a ph.d. at the same time ; not sure I could have done the same with any of the other options in there (an older version was using JUCE but it was full of problems ; in particular JUCE's software renderer is much less efficient than QPainter). And for all of REAPER's goodness, it took decades before getting a linux version.

Re: Thoughts on Rust bloat

#300

Post by nickpsecurity »

jcelerier wrote: post #299
nickpsecurity wrote: post #280

Earlier quoted context omitted.

You might find this article interesting: http://blog.johnnovak.net/2016/05/29/cross-platform-gui-trai...

well, I still think that Qt is the better solution, and so by an order of magnitude :-) it allowed me to write the software, which is being used in production in mac / linux / windows, while doing a ph.d. at the same time ; not sure I could have done the same with any of the other options in there (an older version was using JUCE but it was full of problems ; in particular JUCE's software renderer is much less effici…

Oh yeah, I agree. It's a good one. Several folks in the comments called out the author for not bringing it up. Personally, I think the author had a bias where any solution had to be close to the size of the native, standalone app.

One thing I wondered about Qt is if there's a way to trim out anything an app doesn't use. Have you seen anything like that?

Post reply on HN