6 ms·
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 sha
by csoups14 3y ago
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 that it is limited to expounding "concurrency is hard and I think this concurrency model is easier".
- alex_lav 3y agoIs static typing "safe", and have I demonstrated that simply by publishing a blog about bugs in dynamically typed applications?
- Xeamek 3y agoYes, 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]
- hosh 3y agoI thought binaries (>= 64 bytes) are one of the exceptions to "share nothing" model? They are still immutable though. Also, ETS, which shares data across processes, and may allow multiple writers. Granted, you have to explicitly opt-in for that. And I am assuming we're not considering NIFs, though Rust NIFs makes a lot of sense here.
- zamalek 3y agoLike the students, I assume that the GP hasn't read the original article - which is very clear about what forms of safety it is discussing.
- kaba0 3y agoJust 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.