Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I posted about why this is important for distributed systems engineering:

https://news.ycombinator.com/item?id=46060907

Malloc is fine. We can and do monitor that. It's these undetectable runtime logic problems that are land mines.

In distributed systems, these can cause contagion and broad outages. Recovering can be very difficult and involve hours of complex steps across dozens of teams. Meanwhile you're losing millions, or even hundreds of billions, of dollars for you and your customers.

Someone unwrapping() a Serde wire message or incorrectly indexing a payload should not cause an entire fleet to crash. The tools should require the engineer handle these problems with language features such as Result<>.

Presently, who knows if your downstream library dependency unwrap()s under the hood?

This is a big deal and there could be a very simple and effective fix.

The Cloudflare outage was a multi-billion dollar outage. I have personally been involved in multiple hundred million dollar outages at fintechs, so forgive me for being passionate about this.





I don’t actually work in Rust. I think I understand what you’re going for, though. The choice to use panic as a way of propagating errors is fundamentally problematic when it can arise from code you don’t control and potentially cannot even inspect.

I don’t necessarily agree that malloc should be okay (buggy code could try to allocate a TB of memory and OOMKiller won’t fix it) but I can understand that it’s probably workable in most cases.

Unfortunately I think the fix here would require a compatibility break.




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

Search: