That’s true, but on the other hand, even if we’re 100% certain that we cannot panic, a program that is stuck in an infinite loop (or simply stuck “long enough”) makes the program unable to service requests too. In Rust you’re hosed, in Elixir/Erlang you just get degraded performance, and can kill the offending process without making things inconsistent.
jhogberg
Erlang Core Team
dimitarvp
Not sure we’re talking about the same thing – I’ve coded a fair amount of Golang and Rust services that never had their OS process abort due to these. And it’s not strictly defensive programming btw; it’s utilizing one of the biggest advantages of Rust over many other languages, namely exhaustive pattern matching enforced at compile-time – something that Erlang / Elixir don’t have. In Rust you cannot ignore the error value like you can in Erlang / Elixir – this guarantees no blow-ups.
The code gets verbose fast but I still vouch for Rust. I have created 3 separate API apps that also call other 3rd party APIs and after we fixed an initial flurry of unexpected cases (something that took one week) then the services kept going for a full year, only being stopped for upgrades (which are of course done with blue-green deployments so no actual downtime).
You won’t catch me arguing with that, I preferred Elixir over Golang / Rust as you know. My point was that Rust in particular offers you “compensation” for the lack of a runtime like the BEAM – namely by forcing you to handle every edge case upfront.
People argue this is not interesting or productive but I’ve been on both sides and it’s honestly just a matter of which tradeoff do you prefer.
3
dimitarvp
Yes, and that’s one of the chief reasons why I preferred to make a career with Elixir and not with Rust. You have to be 10x as careful when coding in Rust. I still love it, mind you, but for web / API work Elixir and even Golang are definitely more productive in the initial stages than Rust. Rust can kill your desire to program and make you a potato farmer if you don’t buy its diligence stance.
5
jhogberg
Erlang Core Team
The funny thing is that I do buy its stance on diligence and then some, I actually like the language and I’m not here to dunk on it – I just wanted to provide some perspective that is often lost when thinking about “crashes” and how to deal with them. 
2
dimitarvp
I agree that the distinction and the tradeoffs bear repeating often – thanks for doing it! People easily fall into the “language X is better than Y” trap which, while often true for many languages, absolutely does not apply for the 10-15 top dogs where the game is “pick your poison because they are all good”. To me Elixir and Rust are one of those top dogs.
1
matthias_toepp
What if any, are the ways to write code to make a server crash, using phoenix lets say (aside from using native code)?
0
dimitarvp
- Create atoms above the VM limit (usually 262144).
- Read big files into memory and don’t let the variables keeping them go out of scope – f.ex. spawn a process (not OS process but an Erlang process; very different things), have it read a big file and store it in a variable, and then just have it sleep for weeks.
Phoenix itself is extremely well written and it will not make your server process crash.
1
sbuttgereit
Isn’t it true that what we’re really talking about two tools that are really aimed at different problems?
When I look at Rust, I see something that gets me in close contact with the running system with few abstractions: yes there are rules enforced by the borrow checker, rules about mutable state, and lifetimes, etc. But all of that is to protect me from the low level access I have (and all of which I can bypass with unsafe if I need to). Rust is a systems language.
When working with the BEAM VM, aren’t I really working at a different level of abstraction? Moreso than by using this or that library? A lot of that lower level stuff is dealt with by the BEAM and as an Elixir developer I’m largely protected from those details.
At least that’s my hand-wavy understanding.
I think this is why the earlier “Apples and Oranges” comment is really justified. The trade-offs are different, the guarantees are different, and all of those choices where made in efforts to satisfy different needs. Sure, there’s overlap in applicability, but I’d personally take the larger picture and consider what my application needs the most: many web apps don’t benefit from systems level programming… in which case allowing the good people building the BEAM handle those complexities for me is a win (especially considering they’ll likely deal with that level of complexity better than I would as a business systems programmer). However, at a certain level of performance requirement or computational complexity that situation could change (and even then I might write rust on the hot path and allow the BEAM to orchestrate the whole thing). Trying to straight up compare them without a better sense of these larger goals seems misguided.
Anyway… my two bits.
6
D4no0
I completely agree, different tools for different use-cases.
I think people are getting confused these days because every popular language tries to be “universal”, plus the mix of developers that follow this hype without being able to weight upsides and downsides, or making correct choices for the right technology.
I worked at a small company where they were debating between using go and rust for their services, when in reality the critical thing they needed was reliable uptime. They went ultimately with go (luckily that most probably saved their skin) and made an abomination of infrastructure to assure that reliability, when in reality they could have used elixir/erlang, work less on implementing features from scratch and sleep better at night knowing that everything will work even with errors in the system.
4
matthias_toepp
Certainly the tools are different, to be clear, I’m not asking for a general comparison of Axum vs Phoenix, or which is better or which I should choose. However, in the end, they are also both web servers.
I’m not really asking for a comparison of the tools. It’s just seems too complicated to discuss everything at once… My understanding, and I might well be wrong, is that a rust server will be faster, more memory efficient, and less productive in terms of developer time at the language level, more difficult to scale horizontally, would require a separate tool to supervise and restart a server if/when it crashes, and this does not include a comparison of ecosystems (both language and web frameworks) my requirement or my preference of the feel of the language and community… and I’m absolutely sure I’ve left off many other points of differentiation.
One of the many points of analysis in choosing between server systems is something like uptime. Of course both Axum and a Phoenix server could be restarted almost immediately, so it seems this is not exactly about uptime. It seems the question is rather how much will one server system crash compared to the other and how much does that matter (as a single point of analysis)? If you would have told me that a Phoenix user could under no circumstances crash the server when writing responses (when using the framework as a normal user lets say) then that seems clearly superior to “just remember not to use all the standard language features that can cause a panic…” which seems to be one of the answers given for rust’s Axum. They have also separately pointed out that panics can be caught (through an added middle ware) so that the server doesn’t go down due to a panic, which may mean that the beam doesn’t triumph in this one single regard (but of course has many pros and cons in other regards) I realize that this point of comparison doesn’t address all the other points of comparison which I would have to evaluate for a particular use case.
One of the reasons I’m curious about this is to know if the beam would offer an advantage in this single regard (I know there are other pros and cons) over a system like this GitHub - roc-lang/basic-webserver: A basic webserver in Roc · GitHub , which is roc lang using a rust web framework under the hood. Reliability means a lot to me and I’m trying to understand it in terms of this one dimension (servers crashing).
Thank you for all the responses!
1