Live data from Hacker News

Elixir is still safe

paraxial.io

21–30 of 38 posts

Re: Elixir is still safe

#21
post #15

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.

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.

Re: Elixir is still safe

#22
post #19
post #8

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 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.

The ABS system your car’s brakes could crash — literally — and that would be safe?

Re: Elixir is still safe

#23
post #22
post #19

Earlier 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?

Safe means that every operation has well specified semantics. Some languages, notably C and C++, lack this property.

Re: Elixir is still safe

#24
post #19

Earlier 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?

Then the semantics are not well specified.

Re: Elixir is still safe

#25

Earlier 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?

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]

Re: Elixir is still safe

#26
post #19
post #8

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 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.

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.

Re: Elixir is still safe

#27
post #23
post #22

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.

I would say those languages are both unsafe and have undefined behavior, and these are two seperate issues.

Re: Elixir is still safe

#28
post #22
post #19

Earlier 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?

Ha, this is such a good example of both the advantage of fault tolerant systems and why so many true-to-life computing metaphors fall flat.

Re: Elixir is still safe

#29
post #24

Earlier 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.

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!

Post reply on HN