Re:Rust vs C Pitfalls
by colemickens on Wednesday December 28, 2016 @01:08PM
(#13272312)
(er, "Muslims" was auto-corrected from 'musl' and I didn't catch it until now, sorry)
There are more systems than POSIX and Windows. Also, even in popular Linux systems Rust is not even installable in a straightforward way (e.g. Ubuntu 15.10, my system), so go figure. Regarding Rust bloat, I don't know if has got any better recently, but it was crazy bloated in comparison to C.
Re:Rust vs C Pitfalls
by Manishearth on Wednesday December 28, 2016 @01:01PM
(#13272253)
The bloat issues are (a) a constant overhead and (b) a matter of defaults.
See https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...
Rust statically links to libstd by default because it's not there as a dynamic lib on most platforms. On top of that, it links in jemalloc. This makes small Rust binaries look larger than they need to be. The overhead dwindles as you start looking at larger Rust programs. If you actually need to get rid of that overhead, the option is there, it's just not default.
Addition to popular package managers is being worked on.
Re:Rust vs C Pitfalls
by crossroads1112 on Thursday December 29, 2016 @05:38PM
(#13280810)
Do you not consider adding a PPA to be straightforward? Or downloading the rustup binary and simply running it?
I have a fully static binary that includes futures, nix, tokio, uuid, and more. Even statically compiled with Muslims it's less than three megs.
And if I didn't use the nix package for a setsockopt call, it would be perfectly capable of running on Windows (and I could easily make it cross platform if I wanted to invest the effort in adding Windows support). Further, there are an abundance of great resources out there for extremely painless cross compilation.
So far I've not heard of problems with multiplat or bloat so I'm hoping you'll elaborate.