>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.
Thoughts on Rust bloat
131–140 of 313 posts
Re: Thoughts on Rust bloat
#132Earlier 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.
> 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.
Re: Thoughts on Rust bloat
#133Earlier 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.
> 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.
Re: Thoughts on Rust bloat
#134Earlier quoted context omitted.
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
#135Earlier 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.
Re: Thoughts on Rust bloat
#136Earlier 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.
> 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.
Re: Thoughts on Rust bloat
#137Earlier quoted context omitted.
Isn't it at least partly explained by wanting to allow implementations of this functionality to evolve more rapidly than they could if they were in the stdlib and thus reach good solutions more rapidly? getopt in particular seems like something that programmers haven't reached a consensus on despite 40 years of experimentation.
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…
Re: Thoughts on Rust bloat
#138At 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…
These metapackage communities can then focus on interoperability of constituent packages w/o overburdening the standard libraries, and core language can remain lean and concise.
Re: Thoughts on Rust bloat
#139Earlier quoted context omitted.
> Also be aware that highly inlined code does nicely in microbenchmarks but might have significantly negative performance implications in a larger system when it blows out the I-cache. I see this assertion a lot, but I have never actually seen a system in which inlining that would otherwise be a win in terms of performance becomes a loss in a large system. LLVM developers seem to agree, because LLVM is quite aggressi…
Fiora refactored the MMU code emitted by Dolphin to a far jump, which had significant performance improvements over inlining the code [0]. She had an article about it in PoC || GTFO [1]. [0] https://dolphin-emu.org/blog/2014/09/30/dolphin-progress-rep... [1] https://github.com/angea/pocorgtfo/blob/master/contents/issu...
Re: Thoughts on Rust bloat
#140Earlier 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.
Apples and oranges. It is a feature that Go, Rust don't have "enterprise" standard libraries like Java and .NET.
.NET is an interesting case, because of WinForms, which is a de facto part of the standard library. I think few C# developers think of WinForms as bloat; it's very convenient for making simple UIs. Yet putting, say, GTK+, in the Go standard library would doubtless be considered bloat. I don't think there are easy answers to these questions.