The inevitability of the borrow checker
yorickpeterse.com
yorickpeterse.com
Things like dividing by zero or accessing an index outside of the bounds of an array will panic.
While these aren’t incredibly common, I would never want my whole production web server to go down because some random, infrequently used endpoint had a bug in some edge case.
The language seems heavily inspired by Erlang, which is very resilient to programmer errors in comparison.
In Erlang, the philosophy is to let a lightweight process crash and restart it when there is a problem. This doesn’t need to have any effect on other lightweight processes that are running.
This is exactly how Rust works, for example.
Overall, I'm not entirely sure if Rust would be better or not if panics were non-recoverable.
PS: For completeness, there are flags to control the panic behavior; but you can't rely on them when writing a lib.
> It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below.
I think panics in Rust are intended to be unrecoverable, and catch_unwind is mainly intended to make the shutdown more orderly and possibly localized. Any data structure that paniced is probably in an unknown state that is not safe for further use.
https://github.com/tokio-rs/tokio/issues/2002#issuecomment-6...
And web frameworks like Tower provide standard ways of handling panics and turning them into error responses.
https://docs.rs/tower-http/latest/tower_http/catch_panic/ind...
So I don’t think panics are necessarily meant to be program-killing in Rust, even if Result types are heavily recommended instead.
As a C# and Typescript developer primarily, this concept of killing the whole program due to a bug anywhere in any part of the code is very foreign to me.
I’d expect that to only happen if you ran out of memory, had a hardware failure, or other such catastrophic error. To me, dividing by zero is a problem, but not worse than pretty much any other type of logical error that doesn’t panic.
But getting the wrong answer due to a bug anywhere in any part of the code is not?
Complaints range from too slow to hidden control flow to just not liking them.
I absolutely see the benefit in application code, otherwise you're error checking every function call.
On the other hand, I completely understand not using such a mechanism in kernel and driver code.
But Rust has decided against exceptions (which I actually believe were part of the original vision way back when, but please don't quote me), so now there's panics.
Everything is a tradeoff at some level.
Why single out just a few types of bugs to crash the whole program? Let me catch it and decide what to do.
If it’s in a single request to my web server, I’d like that single request return an error code. I would not like all other concurrent requests for all other users to fail as well.
For runtime error handling you'd use algebraic types such as Result and Option, similar to most functional languages and Rust.
The reason we don't allow catching of panics (such as Rust allows) is because it can result in people more or less ignoring such errors (something I've seen happen far too often in past projects) and just retrying over and over again, achieving the same result every time. I'd much rather have the program crash and scream loudly, forcing developers to address the issue. Fortunately, the chances of you actually running into a panic at runtime should be pretty slim, so not being able to catch them shouldn't be much of an issue in practice.
- Array.get/Array.get_mut for when you want to panic on an out-of-bounds index
- Array.opt/Array.opt_mut for when you want an Option type, with it being a None for an out of bounds index
So for example:
[10, 20, 30].get(0) => 10
[10, 20, 30].get(42) => panic
[10, 20, 30].opt(0) => Option.Some(10)
[10, 20, 30].opt(42) => Option.None
There are a few places where we check for some input at runtime and panic if this is invalid, but this is limited to cases where there's simply no sensible alternative (e.g. providing a key with an invalid size to a ChaCha20 cipher).
That's not scalable if it's not possible to catch panics. If panics can't be handled they must only be caused by super corner 0.001% cases, not by fundamental things like dividing an integer or indexing an array.
I have 2000+ developers at my work, many of them making changes on a single huge web application. Compile/publish of the testing servers takes several hours and happens regularly throughout the day. There are thousands of testers all testing many different workflows all the time.
If one developer makes a mistake in a dark corner of the code one day, it seems bad to have the whole server crashing and disrupting all the other testing that’s going on for multiple hours while we wait for a fix and another build.
Quality and fix prioritization is in the hands of project teams for usability problems, performance problems, functional problems, etc. Uncaught exceptions should be logged somewhere, and it’s ultimately up to the team to decide whether they care enough to fix them.
You do not need to solve that at the language level. A common pattern is using multiple replicas, service discovery and automatic restart upon a dead replica. For example kubernetes does this out of the box.
For dark corners of the code, that is often a good middle ground between interrupting the service and never die.
A crash in a web server could result in data loss, timeouts and performance issues on clients due to the response never coming back, crashes on poorly written clients, cascading failures in poorly written services, etc.
And for a client application, imagine if your web browser would just randomly crash sometimes. Do you think it would make it much better if the browser would detect the crash and relaunch itself? And what if it relaunches itself and then crashes again for the same reason?
In an open source library that I maintain, the C code makes use of asserts. These asserts are essentially unrecoverable panics on constraint/invariant violation. The effect of an assert failure is that violation renders the code unrunnable ("utterly broken"). Unfortunately "panic, go fix it" turns out to not be a great fit for a widely distributed library for at least three reasons: (1) the user of a library is often not in a position to fix it, (2) the distribution is so far removed from the maintainers that the maintainers may or may not get the message to fix it, and even if they can fix it the turnaround time to the next distro release doesn't help the current user very much, (3) if the constraint violations can be triggered by external code then we are essentially introducing "transitive panic" for conditions that we can't possibly fix (we don't control or have visibility into external code, such as Windows APIs and drivers).
The upshot of this is that our policies are to only panic (i.e. use an assert) to check conditions/constraints/invariants that are under the full control of our own code base (never to confirm assumptions about externally supplied data). If we are in a context where it is practicable, prefer raising error conditions such as "internal error" or "unexpected native API response".
With the above in mind, I disagree with your point about supervision trees and restarting lightweight processes. Requiring panics to crash the whole process is the most extreme outcome possible, and can potentially lead to an extremely unsatisfactory user experience. Software is almost always performing many more functions than the little piece of code that panics. I find it difficult to believe that killing the whole process (i.e. unrecoverable panic) is universally the best course of action. Killing and permanently disabling the lightweight process would at least allow the rest of the program a chance to continue in some kind of limp mode until the issue can be fixed.
Looking at it another way, by killing the whole process, you are effectively limiting use to those cases where killing the whole process is indeed the only appropriate course of action.
On "you'll keep running into the issue over and over again and possibly even end up ignoring it" To me this smells over-opinionated and poorly justified. So long as there is good error reporting and diagnostics tracing, the user of the language can and should decide these things. But maybe it can be better justified and maybe there are plenty of use-cases that are fine with "no soup for you!" at the first sign of trouble.
Sorry, but limping along is better than crashing.
Then you need an alternative.
And that alternative is...messy. Do you have exceptions? Do you type them? Or do you have explicit return values? Is there syntax sugar? Etc, etc.
I also like the Erlang philosophy of letting the lightweight process crash as soon as any problem occurs and having a supervisor decide what to do.
I guess checking to make sure you aren't dividing by zero before you divide every time or checking an index access against the bounds of an array could have some performance implications, and also it would be prohibitively hard to actually enforce it across your team?
But the problem is that people make mistakes or forget every once in a while, and as you get more people working on large programs, these mistakes happen more often.
So you have to assume that it'll most likely happen in your production software sooner or later. Crashing the whole program is a fairly catastrophic outcome in my opinion, and should be reserved for only truly unrecoverable problems like hardware failures.
Overflows and divide by zero are easily avoidable and should be fatal.
Even the Apollo lander program aborted and even caused a reboot. Such that the reboot loop caused an uncontrollable lander, just by overloading the IO. The scheduler could have killed the radar process, but this was Aldrin's job, and he failed, not the scheduler.
In C# you can force a type to be stack allocated with "ref struct". https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Terminology is a bit annoying here, as e.g. "reference" can also be interpreted as "a pointer", though it depends on who you ask. I stuck with "borrow" because that just made the most sense to me :)
And the reason for this is that there is no branch needed at the end of the borrow, to check for refCount=0? (Or, is this at least one of the reasons?) I'm wondering about the performance impact for this... There's also the code size impact.
The cost of borrowing (at least with heap types) is an increment upon creating the borrow, and a decrement upon disposing of the borrow. Over time I'd like to optimize those away, but that's not implemented at this time.
`ref struct` allows that struct to contain refs, and disallows putting it on the heap (so, you can't have an array/list of ref structs, and a class or a normal struct can't have a ref struct field)
I assume pjc50 specifically refers to the fact that `ref struct` gives a strong guarantee while a regular struct can be placed wherever.
(that's probably wrong in some subtle ways)
Seems trivial to box the inline types like most languages do.
This is how C++ is designed. Unfortunately, it precludes types from taking dependencies on their own address, which is critical for e.g. atomics. As far as I know, there is no way to actually force a C++ class to be heap allocated. I’ve tried.
Newer languages like Swift give the type designer the ability to say “the address of this object in memory is important and must remain stable for the lifetime of this object.” This decays to heap allocation.
Make the destructor (and possibly the constructors) private, have public factory functions that hand out unique_ptr with a custom deleter, or define a public destroying operator delete (C++20) and use unique_ptr with its default deleter.
It does not! You just have to make it non-copyable and non-moveable. std::mutex and std::atomic do exactly this.
> As far as I know, there is no way to actually force a C++ class to be heap allocated. I’ve tried.
As others have already pointed out: private constructor + factory method. However, this pattern is typically used for different reasons (implementation hiding or runtime polymorphism) and heap allocation is only a side effect.
> This decays to heap allocation.
No! The object might just as well live on the stack or have static storage duration.
It's easier to reason about value semantics than reference semantics. If you want a class with a stable address that is heap allocated, then do so by writing class that has a private field that is heap allocated, preferably managed by a unique_ptr. Then disable copy assignment and construction and make a judgement call if you want to support move assignment, construction.
In effect, the idea is to make this aspect of the type an implementation detail that the user doesn't need to concern themselves with. They just create an instance of the type, and the type deals with the ownership or ensuring that the address is pinned, or whatever other details are needed to make it work. And of course the type does this by delegating that work to unique_ptr or some other means of ownership.
If anything, I’ve found it’s more useful when I want to bypass such wrapping to force a class to use some particular memory (like from a bulk allocation). The STL is pretty good, but there are warts that which still force the default heap allocator like std::function.
There isn't. For this to work, functions for inline types have to be compiled such that one of these approaches is used:
1. They always take inline values by pointer, and we have to guarantee those pointers are never invalidated. This again means you need some sort of borrow checking scheme.
2. We compile two versions for each function: one that takes the data by value, and one by pointer, resulting in significant code bloat and compiler complexity.
I think the split also better captures the intent: heap types are for cyclic and heavily mutated values, inline types are more for short-lived mostly immutable values.
Yes.
Swift made this mistake too. Classes are always heap allocated (and passed by reference and refcounted) and structs are always stack allocated (and passed by value).
It makes for a super awkward time trying to abstractly define a data model: you need to predict how people will be using your types, and how they’re used affects whether you should use struct or class.
The “swifty” way to do it is to just eschew class altogether and just always use struct, but with the enormous caveat that only classes can interop with ObjC. So you end up in an awkward state where if you need to send anything to an ObjC API, it has to be a class, and once you have a lot of classes, it starts to be more expensive to hold pointers to them inside structs, since it means you need to do a whole lot of incrementing/decrementing of refcounts. Because if you have a struct with 10 members that are all classes, you need to incur 10 refcount bumps to pass it to a function. Which means you may as well make that holding type a class, so that you only incur one refcount bump. But that just makes the problem worse, and you end up with code bases with all classes, even though that’s not the “swifty” way of doing things.
Rust did it right: there’s only one way to define a piece of data, and if you want it on the heap, you put it in a Box. If you want to share it, you put it in an Arc.
It always seemed weird to me. You need to know which data type you are working with when passing things around and can not adjust according to the application. For certain types from the standard library it makes sense, like datetimes you probably want always be copied. But when you work in a big team where everybody has their own style and special optimization corner case, it decays quickly.
I appreciate being able to choose which side of the tradeoff (always-copy or heap allocated) you want to be on, but either way be assured it's safe. Not sure how I feel about it in practice without trying it, though :)
1. If you try to define a `mut` field (= one you can normally assign a new value), it will produce an error at the definition site
2. If you try to do something like `some_inline_value.field = value` it also produces an error at the call/assignment site
The actual messages could use some improvements, but that's not a super high priority for the time being as I'm more focusing on the language overall.
I don’t know what inspired borrow checking but I am certain someone else would have thought it up presently if they hadn’t.
I might be wrong here, so please feel free to correct me if so, but I don't think borrowing was a concept, per se, of the language itself.
As you mention, the concept the Rust designers took from Cyclone was explicit lifetimes.
Borrow checking provides two features (but in my opinion in a very un-ergonomic way): (1) prevention of use after free; and (2) temporal memory safety (i.e. guaranteeing no data races, but not eliminating race conditions in general).
I'm still wobbly on PLT legs though; I'm sure there's a pro or ten who could step in and elaborate.
https://homes.cs.washington.edu/~djg/papers/cyclone_memory.p...
or the more detailed discussion throughout this journal paper:
https://homes.cs.washington.edu/~djg/papers/cyclone_scp.pdf
As their citations indicate, the idea of borrowing appeared immediately in the application of subtructural logics to programming languages, back to Wadler's "Linear types can change the world!". It's just too painful without it.
I appreciate the follow up and references.
Now I've got some Friday night reading :)
Myself, I'd lean towards a sound (linear) type theory. If it's not too much trouble, insert the run-time checks in debug builds but use the type system to erase them for optimized builds. It might seem like the mountain is impossible to climb if you're not used to formalizing such systems but every mountain is surmounted one step at a time.
It's hard to bolt-on correctness after the fact. In my experience, for critical pieces like this, it's better to get the specification right first before digging in too deep and writing code.
Best of luck on the project either way you go. Memory safety is increasingly important!
It'd be interesting to see different theories evolve, for sure. Maybe something in separation logic will make it's way into mainstream type theory and into compilers at some point.
What's cool is how much we're starting to see folks push the boundaries these days. :)
Like, rustc only recently gained the ability to explain that the borrow checker rejected a program because a lifetime parameter was invariant. And this isn't even an artificial bit of complexity -- if you have mutability you are required to think about variance. If you have a Cell<&'static str> you cannot just turn that into a Cell<&'a str>, the way you can turn a regular &'static str into a &'a str. (Java programmers might be familiar with similar issues around ArrayList<Object>.)
in rust, &mut means "this pointer points to an initialized value, and will point to an initalized value at the end of scope"
i wish it also had &in, &out, and &tmp, for "initialized->uninitialized", "uninitialized->initialized", and "uninitialized->uninitialized"
But these typestate systems aren't very elaborate usually. I've recently been doing research on the (hypothetical) design of a language which has typestates that can cross function boundaries - you can call a function that annotates that it uninitializes one of its arguments, and then that reference you passed in is now considered uninitialized in your local scope.
> The rationale for this is that at some point, all garbage collected languages run into the same issue: the workload is too great for the garbage collector to keep up.
What this actually means is "The program I wrote is a poor fit for the garbage collector I am using." which can be fixed by either changing the program or changing the garbage collector. People often focus on the latter and forget the former is a possibility[1].
Similarly with single-ownership and borrows, you can write a program that is fighting the memory management system (see e.g. any article on writing a doubly-linked list in Rust).
In other structured memory allocation systems (hierarchical, pools &c.), the memory allocation lends itself well to certain architectures of code.
As far as I know, nobody has done a comparison of various memory management systems and how they enable and hinder various forms of program design.
1: The "time" special operator in SBCL shows allocation and GC time statistics by default. I think this nudges people into thinking about how their program is allocating at exactly the right time: when they are worried about how long something is taking.
Reference counting is garbage collection. I've been on this hill for years, and I am prepared to die here.