Earlier quoted context omitted.
The ABS system your car’s brakes could crash — literally — and that would be safe?
Safe means that every operation has well specified semantics. Some languages, notably C and C++, lack this property.
Elixir is still safe
31–38 of 38 posts
Re: Elixir is still safe
#32Deciding which i should use : Elixir or Clojurescript or python or nodejs
Re: Elixir is still safe
#33Earlier quoted context omitted.
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?
From the original "Elixir is Safe" article: > 3. “Shared nothing” concurrency > 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 tha…
Though there are runtime tools to detect live/dead locks.
Re: Elixir is still safe
#34Deciding which i should use : Elixir or Clojurescript or python or nodejs
Re: Elixir is still safe
#35Earlier quoted context omitted.
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.
Where did you get this definition of safety from? I’ve never heard someone define safety to exclude security issues; that doesn’t seem very useful.
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].
Re: Elixir is still safe
#36Earlier quoted context omitted.
> I just don’t see how it’s so flat. 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,…
“What is sending a message to my process and making it crash?!” “My synchronous reply timed out, so why I am I getting a message after the timeout?!” “Why did deleting my build directory fix the compile error?!” “How do I keep my app from crashing when my supervisor crashed too many times in a given timeframe?!” So many adventures to be had.
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.
Re: Elixir is still safe
#37Earlier quoted context omitted.
Plenty. But I'd take those trivial issues over a blob of microservices any day of the week. In any case, the answer continues to be "it depends". But people will continue to look for "one weird trick" solutions to every problem.
It's fun an games until you have to debug an Erlang RPC call that is timing out w/o log messages in a blob of Elixir micro services.
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.
Re: Elixir is still safe
#38Deciding which i should use : Elixir or Clojurescript or python or nodejs