Without stepping on anyone’s toes, I think we can agree that “safety” could be broken down a bit. Memory safety, thread safety, fine… but there’s a whole forest past those trees.
Is it a safety feature to type-check regular expressions using dependent types? Is Python a security vulnerability because the performance can be unpredictable?
I don’t know.
Rust, for that matter, doesn’t protect you from running out of memory from leaking data on the heap — or from running out of stack space because your infinitely recursive function doesn’t halt. Maybe that’s not part of memory safety — but that’s my point.
There’s a whole safety forest out there. Whenever I read an article about safety in software, it seems like a comfy blanket statement. “This is a nice definition which I will live in.”
Because people like making wild and provocative claims to motivate writing a paper for which the conclusion was already decided.
Anyone who has used, I dunno, any of programming languages that are being discussed has a more nuanced take, and isn't spending time trying to force all things into Box A or Box B.
Elixir/Erlang has a pleasant concurrency model. It does some things well, it does other things less well. It eliminates a big class of bugs, and yet you can still write bugs in Elixir.
These sorts of papers are a waste of space on the internet imo.
For the first you can setup a tracer for messages sent and received. Second should not happen from OTP 24.
Fourth is the wrong question to ask: if the failure handling mechanism is invoked too frequently, fix the failures, not the recovery.
Third is definitely my fault. Bug reports are appreciated whenever possible.
But generally speaking, yes, debugging is part of every programming language, and concurrency and distribution will add to the adventure whenever used, to varying degrees depending on the programming language.
On erlang vm (beamvm), you can safely trace in production. It makes tracing and debugging tools in other ecosystems look like they are primitive in comparison.
I think erlang ecosystem has its own warts like any other one but debugging definitely isn't one
Here are a few examples of what you can do in erlang/elixir:
Inspect function calls that match specific argumrnt patterns, which can get pretty detailed.
Tag processes by id, future processes under a supervisor, or other criteria, and limit tracing to these.
Limit tracing to n occurences. As in automatically disable tracing after it triggered n times.
Typically one combines these and more to identify issues pretty rapidly.
tracing Erlang in prod is literally a fun game, and very easy. Like...one of the best things about the ecosystem. The dbg module (part of the stdlib) is your friend. Trace messages, function calls, with as wide or as specific a net as you need. I've found bugs quickly that would have taken a lot of trial and error on other platforms.
Safety means no undefined behavaior. It does not mean free of bugs, or security issues, or free from crashes. It simply means every operation has well specified semantics.
Typically you would start with [0] and it's derivations for specific domains.
The core idea is "The fundamental concept is that any safety-related system must work correctly or fail in a predictable (safe) way."
The interesting question is what to do in corner cases you did not specify explicitly. Typically it is still considered "safe" if you don't do what you would have specified in hindsight, but fall into the defined failure reaction. You also try to make security problems take that path.
Checking that the system does what is specified is called "verification" and the domain of functional safety. Checkin that this is what you actually meant (it actually solves the user's problem) is called "validation" and especially for vehicles called SOTIF [1].
The point being made here is that you can be infinitely specific and still run into unexpected failures. If you're going to claim there is a way out of that you are either very young of just straight up lying.
We're talking about Erlang here which, to my knowledge, is the only mainstream-ish general-purpose programming language that was developed to solve an actual business problem. To be that guy that quotes a relatively well-known quip that maybe you've already heard, the unofficial tagline was: "Remember in the 90s when your phone company would call you up and say that you can't use your phone for a few hours for 'planned maintenance'? Of course you don't... and that's tanks to Erlang."
That was accomplished because you can just specify the happy path, deal with well-known exceptions (are they really "exceptional" at this point?), and otherwise just turn it off and on again, as we all do. And, not to start a flame war, but it's a dynamically typed language to boot!
Often journals will accept "letters" in some form or another if the criticism is brief, and do on occasion publish full papers addressing the shortcomings of another.
When that fails, usually one would try another journal or two, and after that it's usually some manner of blog posting and social media.
> Practitioner perceptions are formed through personal experience, and not based on empirical evidence
The disagreement here is rooted in the empirical worldview. Empirically, "rarely" and "never" cannot be (reliably) distinguished, and so adherents of this worldview fail to distinguish claims which are meant to distinguish them.
The original article didn't disprove the existence of vulnerabilities though. Is "Concurrency is hard and I think this concurrency model is easier" "proof"? Did you read either article?
> Item 3 is the killer one for safety. Like two people, two processes cannot share memory; they can only communicate by sending each other messages.
This makes impossible an entire class of thread safety issues. "Elixir is Safer" might have been a better phrasing, but you're misrepresenting the contents of the article if you're claiming that it is limited to expounding "concurrency is hard and I think this concurrency model is easier".
Just so people don’t get the bad idea, message passing is still prone to the general category of race conditions, just not data races (without shared memory).
Though there are runtime tools to detect live/dead locks.
Yes, if you demonstrate that entire class of bugs are ommited simply by the language inherently having some feature (like types) then it's a decent argument that this language is safer, or even completely safe [from the specific type of bugs]
Weird set of choices.
So clojure and elixir can be your hooks into fp community. To a degree they are similar in being dynamic fp langs with macro capabilities.
Python and node are more like "common dev platforms" these days.
I would first establish if I am looking for job market utility (both elixir and clojure offer great utility, but job market is more problematic). Yet if you are looking to learn and expand your dev horizons elixir or clojure are great options (I do clojure so a bit biased towards it).
That really really depends on what you want to do, can you add a bit more information? Also those choices are not mutually exclusive, you can run Clojurescript on Node.js, but you would probably be better off using normal Clojure.
Is it a safety feature to type-check regular expressions using dependent types? Is Python a security vulnerability because the performance can be unpredictable?
I don’t know.
Rust, for that matter, doesn’t protect you from running out of memory from leaking data on the heap — or from running out of stack space because your infinitely recursive function doesn’t halt. Maybe that’s not part of memory safety — but that’s my point.
There’s a whole safety forest out there. Whenever I read an article about safety in software, it seems like a comfy blanket statement. “This is a nice definition which I will live in.”
I just don’t see how it’s so flat.