i aspire to make software that is piss easy to package, which is why i will never touch rust again
-
i aspire to make software that is piss easy to package, which is why i will never touch rust again
-
i aspire to make software that is piss easy to package, which is why i will never touch rust again
@kimapr what about rust makes packaging difficult? i think i've heard it before but i can't remember or find details -
@kimapr what about rust makes packaging difficult? i think i've heard it before but i can't remember or find details
@SArpnt@fe.disroot.org honestly i forgot the details myself but i found this blog post about it https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ (it doesn't single out rust but a lot of it applies to rust)
it seems to come down to rust encouraging terrible development practices. rust has no stable ABI at all, so all rust software statically links each other, which means that if one rust library has a vulnerability, everything that uses it has to be rebuilt. worse yet, everyone pins specific, potentially severely out-of-date versions of dependencies to shield themselves from constant API breakage. because packagers care about security they obviously cannot accept this, so they unpin the versions, and because no one ever tests rust software that way and because the rust ecosystem does not care about API stability it would often break.
basically, rust encourages devs to move fast and break things, and packagers are left to clean up the mess after them. Go also does this but i've never used Go so not as familiar with it.
there's also the thing about rustc itself being near-impossible to bootstrap, rustc is written in Rust, but not just any Rust, it uses nightly-only features from the previous version of rustc. So to bootstrap it you have to go all the way from ancient versions of rustc, build the next version, and so on and so on, it's hell. Seems like the way Gentoo goes about this is to just give up and make the rust package depend on rust-bin.
-
@SArpnt@fe.disroot.org honestly i forgot the details myself but i found this blog post about it https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ (it doesn't single out rust but a lot of it applies to rust)
it seems to come down to rust encouraging terrible development practices. rust has no stable ABI at all, so all rust software statically links each other, which means that if one rust library has a vulnerability, everything that uses it has to be rebuilt. worse yet, everyone pins specific, potentially severely out-of-date versions of dependencies to shield themselves from constant API breakage. because packagers care about security they obviously cannot accept this, so they unpin the versions, and because no one ever tests rust software that way and because the rust ecosystem does not care about API stability it would often break.
basically, rust encourages devs to move fast and break things, and packagers are left to clean up the mess after them. Go also does this but i've never used Go so not as familiar with it.
there's also the thing about rustc itself being near-impossible to bootstrap, rustc is written in Rust, but not just any Rust, it uses nightly-only features from the previous version of rustc. So to bootstrap it you have to go all the way from ancient versions of rustc, build the next version, and so on and so on, it's hell. Seems like the way Gentoo goes about this is to just give up and make the rust package depend on rust-bin.
@kimapr this sounds more like the kinds of people that program in rust want ergonomic dependencies fast and don't consider this kind of security, not that the choice of language matters all that much. if c programmers constantly changed their library apis it would cause the exact same issues, and rust does provide plenty of tools to make and work with stable abis.
javascript doesn't even have abi and it's had all the same kinds of dependency related security problems for years.
i still agree that bootstrapping and abi need some serious ergonomic work, i've been thinking on how to design some kind of general purpose abi specification language since reading [faultlore's abi blog posts](https://faultlore.com/blah/c-isnt-a-language/) and wanting better control over abi for various projects -
R relay@relay.mycrowd.ca shared this topic
