Hacker News new | past | comments | ask | show | jobs | submit login

Correct, with the implication that by creating incentives to bundle junk tech debt into 'AAA' packages (packages with good reputation), the Rust ecosystem is heading for a bubble (and eventually a collapse) because the rating agency that's supposed to regulate things has been gamed.



Do you think that implication is correct? If so, how do we fix it? Of course, companies should pay for what they use, but how do we practically implement that?


I feel like the analogy does not quite hold because when the junk debt was vendored in, the maintainer actually has more knobs than before to fix the problems - and if it's as easy as bumping some dependencies and fixing a few method signatures, it might actually happen.

Whereas in the 2018 crisis, junk debt was rolled into CDOs but there were no 'knobs' the bankers could turn to actually improve the fundamentals of the junk debt. By repackaging the debt they did not get any right to fix the bad actors that made it bad. Things were actually bad, and when it defaulted there was insufficient firewall to prevent the contagion from affecting the encapsulating derivative.

Of course it is up to the maintainer but by absorbing an abandoned project, they are actually reducing the amount of unmaintained code, versus simply hiding it.

Probably the more accurate analogy to 2018 would be if a private equity firm started a company you could pay to upgrade the rating of an unmaintained Rust package, but no actual change happened and all they did was swap labels on things until the problematic rating disappeared.


Great question. One thing to remember is that the value of a piece of software that’s heading towards being un-maintained is much lower than one that has a clear maintenance path. One should be wary of single-maintainer projects. That said, the number of maintainers and the amount of code per maintainer would seem to be the important variables. In this case the code has moved from a repo with one (albeit absent) maintainer to another with one maintainer. Let’s call that neutral. However our new maintainer now has much more code to maintain so the risk has measurably gone up. It might be worth also taking into account how much code in total someone is responsible for across the cargo ecosystem.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: