3 ms·

So slicing is forbidden in this scheme? But not malloc? This doesn’t seem to be a principled stance on making the language safer. It feels a bit whack-a-mole.

by dpark 11mo ago

So slicing is forbidden in this scheme? But not malloc? This doesn’t seem to be a principled stance on making the language safer. It feels a bit whack-a-mole. “Unwrap is pretty easy to give up. I could live without slicing. Malloc seems hard though. I don’t want to give that up.”

echelon 11mo ago
I posted about why this is important for distributed systems engineering: https://news.ycombinator.com/item?id=46060907 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.
- dpark 11mo ago
  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.

by dpark 11mo ago

echelon 11mo ago

I posted about why this is important for distributed systems engineering: https://news.ycombinator.com/item?id=46060907 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.

dpark 11mo ago
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.