How much more crashproof is a server with Elixir/Beam compared to Rust's axum?

This is comparing apples with oranges. Rust is all about preventing crashes. The BEAM is about allowing for crashes by isolating them as best as possible and letting the system as a whole stay up even in the face of things going sideways in a context, where things going sideways by definition cannot be prevented – distributed systems communicating over networks.

“Comparing apples with oranges” to me implies the question is inappropriate or invalid.

I’m wanting to know if a phoenix server will crash less often than an Axum server and how much that really matters.

It’s not that, but there simply is not general answer to your question. What even is “crashproof”? I can build you a server, which never gets any work done e.g. just returning a 500 on any request, but their process never stops. Is that “crashproof”? Probably depending on the definition. Is it useful? Not at all.

I’m not sure what do you mean by that, Rust’s main goal is no bugs in runtime, elixir puts more focus on graceful recoveries from crashes.

It depends on a use case, i tried Axum when i already read most of the rust book but it was still really hard for me to do even simple crud so i gave up as i figured out that maybe i don’t need that much safety and performance.

I picked elixir because it was easy to learn, offered nice syntax, was relatively safe and very performant in areas that matter for a web development project while being fault-tolerant.

By crashing I mean that a server has been started and no longer responds to requests.

Elixir does not do that. It will always tell you something even if you wait 30s for it. You’ll still get an error, or the OS process will be killed by f.ex. Linux’s out-of-memory reaper and then obviously nothing will get served as the server will not be there.

Your original question’s answer is: Rust can still crash and burn. You can write very defensively f.ex. never use .unwrap but maybe your colleague will have had a bad morning and will put it in. Then when you hit that place in the code and there’s no (or errored) value the entire OS process aborts.

Elixir does not do that – one error never brings down the entire OS process.

To expand a little on Rust: both Axum and ActixWeb are amazing frameworks and I am certain you’ll never have an OS process crash because of them. Still, you the developer can write a non-crash-proof code inside your responders / handlers and then all bets are off.

In Elixir you can straight up try writing this inside your controller function(s):

something = nil
IO.inspect(something.inserted_at)

Which is an error, but nothing will stop, just one request will fail and everything else goes as normal with zero capacity affected.

In Rust, if you write this:

value = None;
stuff = value.unwrap();

Then your entire program might get aborted and die on the spot. Though final disclaimer: I haven’t looked at Axum and ActixWeb in at least a year so maybe double-check; maybe they have added protections against defective code like this since the last time I checked them out.

A quick glance shows that there are some plugins to catch panics, but I feel compelled to add that “added protections” of this kind give people a false sense of security.

Yes, they let you ignore the error that just happened, but in doing so you also ignore any side-effects that occurred up to the point of the crash, potentially leaving your program in an inconsistent state (from the program’s point of view, not necessarily the language’s). Half the selling point of Elixir/Erlang, IMO, is that it gives you decent tools to handle this.

Yes. Rust has no runtime to speak of (tokio is kind of sort of a runtime but it’s not nearly rich on features as the BEAM VM) so basically if you don’t code defensively all bets are off.

Though in the spirit of a balanced discussion, Rust’s ecosystem has world-class tooling to help you scan for e.g. unsafe (via cargo-geiger) and you can also use a variety of linters or even roll your own (through ast-grep, gritql or just plain old grep or rg) and just disallow stuff like .unwrap at all. So a diligent Rust programmer – and I’ve worked with 15+ of them – will still have programs that don’t crash ever. But you’re right: that’s because the programmers are diligent and is not owed to the runtime. With Erlang / Elixir, the runtime is always there to catch us when we fall.

This is not a thing that is possible once external things that can misbehave are added to the equation. The simplest example would your controller doing a http request to another service. You can have a lot of things that can go wrong:

1. The service is down;
2. The service decided that they want to make a breaking change to their contract;
3. The network request failed for a reason or another;
4. You are hitting a timeout.

Unless you have covered all these edge-cases and more, you are never guaranteed that this thing will not blow up in your face, no matter how many compile-time guarantees you have. I think this is the exact point where defensive code becomes a liability and the perfect place where erlang VM excels, the system continues to work and you can decide later if you want to handle specific edge cases or some partial errors are acceptable.