> But many operations in Rust can panic, from out-of-bounds indexing to calls into user-provided code, and by default a panic unwinds

That's why I think having unwinding in Rust is a mistake. It gives a false sense of safety, but it's very hard to write unwinding-correct code. So, it would be better to handle panics as immediate process termination instead.

▲

Xirdus an hour ago | parent [-]

But that would make Rust unsuitable for writing anything that wants to keep the program running even if something does panic - say, test harness, or a plugin system.

▲

cowlevel 17 minutes ago | parent | next [-]

This is already the case for any other non-JVM language though, and they usually manage to deal with it by separating operating system processes. A lot of C programs have plugins (even the kernel!) and don't crash because the plugins aren't buggy (by which I don't mean they have no bugs).

Your plugin can still crash in ways other than a panic, like a segfault inside an unsafe block.

It's also likely possible to DoS the application from a plugin in ways other than a crash, e.g. add a billion entries to the right-click menu.

And if you're loading a plugin, how do you know the plugin was actually written in Rust, anyway? It could be written in C and scribble over all your stack memory as soon as you load it.

It's very hard to guarantee stability in the presence of arbitrary extensions, and you might not even want to because someone might have a real use case for an extremely large right-click menu (probably not a billion though). I don't think even language server protocol guarantees it.

▲

masklinn an hour ago | parent | prev [-]

OTOH that panics are ok and easy to reach for and unwind is why you have to handle them and keep the program running.

I don’t think that an unwind-less rust would have fit within the weirdness budget 10 years ago, today it would definitely be something to consider. Although it would have an unwind effect to contend with.

▲

Xirdus an hour ago | parent [-]

It would be entirely unsuitable for the kind of project I work on in my day job, which requires running user-provided code (trusted code, but one that may contain many bugs) in 100 different worker threads, and if one of them crashes the other 99 must keep running. Without unwinding and recovery, we'd have to completely redesign the whole application, probably to multiprocess architecture with all its downsides.

	▲	cowlevel 15 minutes ago \| parent [-]
		What do you do if they segfault on raw pointers? Does Rust's runtime catch SIGSEGV and translate it to a panic? You can also get SIGBUS by mapping a file beyond the end of the file and then trying to read the extra bytes. If Rust's version of mmap checks this, you can still do it by truncating the file while it's mapped.