Well, not exactly, it means that "immunity" may actually be dangerous or fatal. Because immunity implies release of antibodies on re-exposure, except in this case the antibodies bind to the virus, as normal, but then the virus infects much more readily, prompting the body to produce more antibodies and mount an ever greater immune response in a dangerous cycle.
I don't know much about the actor model. One of these days, I should look into it more. It's possible that there's a large overlap.
The basic idea in agent-based modeling is that you have a bunch of different types of objects, which we'll call "agents." Each agent has its own independent state, which typically includes location and one or more other variables. So far, that sounds like regular ol' object-oriented programming.
However, there are some differences. First, you have all agents of one type act at the same time, at the tick of a clock. You can then say, "Hey! All doctors! Move in the direction of the closest sick patient." You can similarly say, "Hey! All patients! If there's a doctor next to you, then you have a 30% chance of being cured." Then you create a population of doctors and patients, randomly infect some proportion of the patients, and run the model.
The code for what I've just described is very short and very readable. And it does away with the need for loops. You basically describe the action that a class of agent will take at any given moment, and then tell the agents to perform one or more actions.
Again, it makes much of the programming simple and easy to understand. And yet, you can write pretty complex models in this way.
For example, I implemented the Autumn model ( http://ccl.northwestern.edu/netlogo/models/Autumn ) for NetLogo (because my eldest child was asking why leaves change color when we lived in Chicago). So I created a model in which each leaf has some randomly set values for each of the chemicals that affect color change. Then I let the user adjust the temperature and rainfall. The leaves changed colors as a result. It didn't take me much time to implement, and turned out to be a great learning tool.
Agent-based modeling isn't great for everything, but it's great for many things -- especially for modeling complex systems.
Basically a NIF blocks the scheduler, so if you run a tight loop for a long time, there will be no preemption. Therefore, invoking foo(), where a foo is a NIF which runs for say 10 seconds, means a single process will get 10 seconds of uninterrupted scheduler time, which is way more than other processes not calling that NIF.
There are ways of addressing that (called dirty schedulers), but the thing is that you need to be aware of the issue in the first place.
If due to some bug a NIF implementation ends up in an infinite loop, then the scheduler will be blocked forever, and the only way to fix it is to restart the whole system. That is btw. a property of all cooperative schedulers, so it can happen in Go as well.
In contrast, if you're not using NIFs, I can't think of any Erlang/Elixir program that will block the scheduler forever, and assuming I'm right, that problem is completely off the table.
As linked elsewhere here, tight loops that never preempt are being fixed in Go 1.8/1.9[0]. Looks like a flag may been added to Go 1.8 called "GOEXPERIMENT=preemptibleloops" that adds a preemptible point at the end of a loop. It's behind a flag for performance/testing reasons, but they are working on it.
