Earlier 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.
Elixir is still safe
21–30 of 38 posts
Re: Elixir is still safe
#22Without 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 mem…
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.
Re: Elixir is still safe
#23Earlier 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.
The ABS system your car’s brakes could crash — literally — and that would be safe?
Re: Elixir is still safe
#24Earlier 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.
>It does not mean free of bugs What if there is a bug in those well-specified semantics?
Re: Elixir is still safe
#25Earlier quoted context omitted.
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…
Is static typing "safe", and have I demonstrated that simply by publishing a blog about bugs in dynamically typed applications?
Re: Elixir is still safe
#26Without 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 mem…
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.
Re: Elixir is still safe
#27Earlier 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.
Re: Elixir is still safe
#28Earlier 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.
The ABS system your car’s brakes could crash — literally — and that would be safe?
Re: Elixir is still safe
#29Earlier quoted context omitted.
>It does not mean free of bugs What if there is a bug in those well-specified semantics?
Then the semantics are not well specified.
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!